OmniAudit MCP server with AuditLens, SiteLint, and Release Butler
OmniAudit defines 17 tools across three modules (AuditLens, SiteLint, ReleaseButler, Core) with explicit JSON schemas and descriptions. All tools have input schemas with typed properties and most have descriptions (10 - 150 chars). However, descriptions are often terse and lack actionable context for LLM selection. Parameter descriptions are sparse or missing entirely, most params lack guidance on format, constraints, or dependencies. Output schemas are not documented. Error handling is minimal. Tool naming follows verb_noun convention but some names are generic (e.g., 'get_job', 'list_receipts'). No confirmation patterns for destructive operations (create_issue, create_release, export_report). Composition is reasonable, tools chain via IDs, but some tools conflate multiple concerns (e.g., create_release uploads assets in one call).
Create a GitHub issue from findings.
Fetch and store evidence artifact from a workflow run.
List GitHub workflow runs for a repository and optional PR/branch.
Parse normalized findings from stored evidence reference.
Generate a read-only patch preview for a finding.
Get a job by ID.
Return service health and configuration summary.
Parameter descriptions missing or minimal. Most params (e.g., 'repo', 'job_id', 'scan_id', 'tag') lack guidance on format, constraints, or valid values. LLMs cannot infer whether 'repo' means 'owner/name' or just 'name', or what 'job_id' format is expected.
Output schemas not documented. Tools return data but LLMs have no schema to understand response structure, field types, or what IDs/references are available for chaining. This forces agents to guess or make exploratory calls.
Destructive operations lack confirmation patterns. create_issue, create_release, and export_report modify state but have no dry-run, confirmation_token validation, or explicit user-approval step. Agents can accidentally create duplicate issues or releases.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
List receipt history.
Create a new GitHub release and optionally upload local asset paths.
Generate release notes from tag-to-tag compare with deterministic fallback.
Get latest release metadata.
List assets for a release tag or latest release.
Verify release asset checksum.
Export scan report to a destination file.
Return scan report data.
Get job status for a site scan.
Start a site scan and return a job reference.
Tool descriptions are terse (45 - 65 chars average). They state WHAT but not WHEN to use or dependencies. E.g., 'Get job status for a site scan' does not explain that start_scan must be called first or what job_id format is expected.
Generic tool names reduce clarity. 'get_job' and 'list_receipts' are vague, they do not convey domain context. Renaming to 'get_scan_job' and 'list_audit_receipts' would improve LLM disambiguation when many tools are available.