Skip to main content

​
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.

​
Tool safety annotations

Every tool returned by tools/list carries an annotations object with four MCP-standard hints: 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, 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. 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