> ## Documentation Index
> Fetch the complete documentation index at: https://docs.auditynow.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP Capabilities: Annotations, Prompts, Resources & Structured Output

> What an instruction-aware MCP client sees beyond the tool list: safety annotations, ready-to-run prompts, a read-only resource shelf, and schema-validated structured output.

## Beyond tools/list

The Audity MCP server (`https://app.auditynow.com/api/mcp`) exposes three MCP capabilities, `tools`, `prompts`, and `resources` (declared in the server's `initialize` response), plus per-tool metadata that rides along with `tools/list`. This page covers everything except the tools themselves: safety annotations on every tool, the prompt recipe menu, the read-only resource shelf, and structured output for the read tools that declare one.

The server exposes 100+ `audity_*` tools; the live `tools/list` response is always the authoritative count and catalog. Any instruction-aware client (Claude, Cursor, and similar) picks these capabilities up automatically, nothing extra to configure beyond the normal [connect setup](/guides/connect-cli).

## Tool safety annotations

Every tool returned by `tools/list` carries an `annotations` object with four MCP-standard hints:

| Hint              | Meaning                                                                                                               |
| ----------------- | --------------------------------------------------------------------------------------------------------------------- |
| `readOnlyHint`    | `true` if the tool never mutates state.                                                                               |
| `destructiveHint` | `true` if the tool removes something from view, even if the underlying change is soft/restorable.                     |
| `idempotentHint`  | `true` if calling the tool again with the same arguments converges on the same end state.                             |
| `openWorldHint`   | `true` if the tool reaches outside Audity (the public web), rather than only reading/writing your own workspace data. |

The rules a client can rely on:

* **Every `audity_get_*` and `audity_list_*` tool, plus `audity_export_project_json`**, is a read: `readOnlyHint: true`, `idempotentHint: true`, `destructiveHint: false`, `openWorldHint: false`.
* **Every other tool is a write**, `readOnlyHint: false`. Within writes:
  * `destructiveHint: true` only for `audity_delete_assessment_question`, `audity_archive_project`, and `audity_archive_lead`, the three tools that remove something from an active view even though the change is soft/restorable. Every other write is `destructiveHint: false`.
  * `idempotentHint: true` for every `audity_update_*` tool and for `audity_select_opportunities` (re-sending the same selection converges on the same state). Every other write tool (`audity_create_*`, `audity_add_*`, `audity_enqueue_*`, `audity_upload_document*`, and the rest) is `idempotentHint: false`.
  * `openWorldHint: true` only for `audity_enqueue_web_research` and `audity_enqueue_prospect_research`, the two tools that fetch from the public web. Every other tool, read or write, is `openWorldHint: false`.

A client that respects these hints can, for example, auto-approve read-only calls while still confirming destructive or open-world ones, without hardcoding a per-tool allowlist.

## Prompts

`prompts/list` returns four ready-to-run recipes; `prompts/get` renders one into a single user-role message with your arguments interpolated. Each prompt is grounded in the same pipeline order and posture as the [Guided Audit Conductor](/guides/audit-conductor), calling one doesn't require you to also invoke `/audit` or any special mode, it's just a pre-written instruction your agent executes with its normal tool access.

| Prompt                  | Arguments                                                           | What it does                                                                                                                                                                      |
| ----------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `run-full-audit`        | `client_name` (required), `industry`, `company_size`                | Runs the full audit pipeline end to end for a client, pausing only at the two content forks (which opportunities make the cut, which deliverables to generate).                   |
| `triage-leads`          | `min_score` (default 70), `timeframe` (default "this week")         | Lists high-scoring leads for a timeframe, summarizes them with IDs and scores, and recommends which to convert, without converting anything itself.                               |
| `generate-deliverables` | `project_id` (required), `deliverables` (default "pdf,gamma,memos") | Enqueues the selected deliverables for a project in parallel, then polls each job and confirms actual readiness (not just that generation was triggered) before reporting a link. |
| `nucleus-review`        | `topic`                                                             | Searches Nucleus memories and insights on a topic, groups by type, and flags anything under 0.8 confidence as a hypothesis rather than a fact.                                    |

In a client that surfaces MCP prompts as slash commands or a picker, these show up alongside your own custom prompts. Calling one with missing required arguments is a client-side validation error, `prompts/get` expects `client_name` for `run-full-audit` and `project_id` for `generate-deliverables`.

## Resources

`resources/list` returns a read-only "deliverables shelf" built from your own most recent projects, no separate authorization step beyond your normal PAT. Two resource kinds exist per project:

* `audity://projects/{projectId}/deliverables`, listed when the project has a current audit analysis or (fallback) any business analysis.
* `audity://projects/{projectId}/final-report`, listed when a compiled final report exists for the project.

Both resources report `mimeType: application/json`. The final-report resource intentionally deviates from a plain-text/markdown expectation: `report_data` is a compiled JSON object (project info plus document/interview/audit analysis sections), never markdown prose, so labeling it `application/json` is the accurate shape rather than telling a client to render JSON as markdown.

`resources/list` inspects your 20 most recently updated projects and returns at most 40 resource entries total, so very large workspaces see a recent-first slice, not the full history. `resources/read` validates the URI (unknown kind, malformed shape, or a non-UUID project ID all fail before any data is fetched) and returns the exact same JSON body the matching tool (`audity_get_deliverables` or `audity_get_final_report`) would return for that project, the two surfaces cannot drift apart because they share one code path.

## Structured output

14 read tools declare an `outputSchema` on their `tools/list` entry, and their `tools/call` result carries the same payload twice: once as the usual JSON-stringified `content[0].text` (for any MCP client), and again as a `structuredContent` object (for clients that want to validate the result against the tool's declared `outputSchema` without re-parsing text). The two are always the identical object, never independently derived.

The 14 tools with a declared `outputSchema` (as of this writing; the live `tools/list` response is authoritative for which tools currently declare one):

`audity_get_navigation_status`, `audity_list_projects`, `audity_get_project_analysis`, `audity_get_project_opportunities`, `audity_get_job`, `audity_list_jobs`, `audity_list_leads`, `audity_get_lead`, `audity_get_credits`, `audity_get_tier`, `audity_list_memories`, `audity_list_project_documents`, `audity_get_roi_calculations`, `audity_get_assessment_results`.

Every other tool, including `audity_get_deliverables`, has no `outputSchema` and no `structuredContent`. `audity_get_deliverables` is a deliberate omission: it returns four distinct success shapes depending on project state (business-analysis fallback, full audit view, an auto-degraded summary view, and a `success: false` "no analysis yet" response that is not an error), so a single schema would either misdescribe most of those branches or be so loose it added no value. Free-form or AI-generated fields inside the 14 declared schemas (job metadata, detailed analysis blobs, ROI calculation inputs/results) are typed as a loose, nullable object rather than a falsely precise shape, a schema-validating client should not reject a valid response just because one of these fields' internal shape varies.

## What's next

* [Guided Audit Conductor →](/guides/audit-conductor), the `instructions` brain and pipeline orchestration
* [Connect with one command →](/guides/connect-cli), MCP server setup and the full tool count
* [API Reference →](/api-reference/openapi.json), the REST surface for clients without MCP support