Lints a phone voice agent prompt and platform config before real callers reach it.
Scored across 3 tools
The three tools occupy clearly separate niches: listing all rules, explaining a single rule, and running the linter on an agent. There is no plausible way to confuse them, and each description scopes its operation precisely.
All names follow a consistent verb_noun snake_case pattern (list_lint_rules, explain_lint_rule, lint_voice_agent) with the verb leading. The naming is predictable and readable across the whole set.
Three tools is well within the ideal range and each earns its place: one to discover rules, one to inspect a rule, one to run the check. For a narrowly scoped static linter this is neither thin nor bloated.
The core lifecycle is covered: run the linter, enumerate rules, and look up a rule's details. Minor gaps exist, such as no way to lint multiple agents/configs in one call or retrieve rule-set versioning, but agents can work around these easily.
Explain one Voice Agent Linter rule by id: why it exists, a bad and a good example, the fix, the platforms it applies to, and its sources with the date each was read. Static reference, no network access.
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes | The rule id, for example no-live-date, vapi-nested-item-enum or no-ai-disclosure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real context beyond that: 'Static reference, no network access' confirms the closed-world behavior and it enumerates exactly what each explanation contains (rationale, bad/good example, fix, platforms, dated sources), which sets expectations for the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence naming the verb, resource, and output contents, followed by a short clarifying clause. Every element earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by enumerating the return contents (rationale, examples, fix, platforms, dated sources). For a single-enum-parameter read tool with full annotations, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the enum fully enumerates the 37 valid rule ids, so the schema carries the parameter burden. The description adds only the concept of 'rule id' and no format or applicability detail beyond what the schema already states, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Explain one Voice Agent Linter rule by id') and scopes it to a single rule. It is clearly distinguishable from lint_voice_agent (runs a lint) and list_lint_rules (enumerates rules) without consulting their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by id' framing implies this is the lookup used once a rule id is known, and the enum supplies the valid ids, so discovery needs are covered indirectly. However, the description never explicitly says when to use this versus list_lint_rules or what to do when an id is unknown, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a phone voice agent’s system prompt and, optionally, its config JSON (Vapi assistant, Retell agent or LLM, ElevenLabs agent, or OpenAI Realtime session) against rule-based checks learned on live calls. Finds: no live date and dates without a year; phone numbers, emails, URLs, hyphen ranges and long numbers the voice will misread; no spelling protocol or bare-letter spelling; instructions to pass as human, missing AI disclosure and missing recording notice; scripted tool start lines, stall phrases and silent or long openers; tools with no description, untyped or undescribed parameters, undefined required fields, unformatted date parameters and unstated results; Vapi nested item enums, flat analysisPlan keys, disabled plans and plans without the transcript; ElevenLabs Turbo stutter risk; no transfer or callback path and no end-call; placeholders, secrets, very long prompts and contradictory always and never rules. Each finding has a rule id, severity, the exact line (and JSON path for config), an excerpt, a specific message and the fix; disclosure and recording rules carry their legal citations with the date read. Returns a 0 to 100 score and a verdict. Do not paste credentials: API keys, bearer tokens, passwords and the values of secret-named config fields (apiKey, secret, token, password, credentials, Authorization) are stripped from the input before any check runs and replaced with "[secret removed]", so they are never read, returned, logged or stored; the output says how many were removed. No model reads the input and nothing is stored. Informational, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Which platform the config is for. "auto" detects it from the JSON. | auto |
| config_json | No | The agent’s config as a JSON string, exactly as the platform exports it (remove keys first; any left are stripped before checking): a Vapi assistant, a Retell agent and/or LLM (or {"agent": ..., "llm": ...}), an ElevenLabs agent, or an OpenAI Realtime session or session.update event. | |
| min_severity | No | Only return findings at or above this severity: critical, high, medium or low. | low |
| first_message | No | The opening line the agent speaks, when it is not in the config. | |
| system_prompt | No | The agent’s system prompt, as plain text. Optional when config_json contains it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that secrets are stripped before any check runs and replaced with '[secret removed]', that the count removed is reported, that no model reads the input, that nothing is stored, and that the tool is informational, not legal advice. It also describes the output shape (0-100 score, verdict, per-finding rule id/severity/line/excerpt/message/fix) and that disclosure/recording rules carry dated legal citations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, but the long semi-colon-delimited enumeration of every check class is dense and could be delegated to list_lint_rules. Every element is topically relevant, but the size is disproportionate and hurts scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: it explains the score/verdict and the structure of each finding, plus specifies the accepted config formats and secret-handling behavior. Nothing an agent needs to call it correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each of the 5 parameters and the two enums. The description largely restates the prompt/config/optional-config concepts that the schema already carries, adding little format or syntax detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check a phone voice agent's system prompt and, optionally, its config JSON') and enumerates exactly what it looks for across named platforms. This is clearly the active linting tool versus the sibling docs tools list_lint_rules and explain_lint_rule, so an agent can distinguish it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to use it ('Check a ... system prompt and, optionally, its config JSON ... against rule-based checks') and covers both prompt-only and config-provided cases. It does not explicitly name the alternatives (list_lint_rules / explain_lint_rule) or state when not to use it, so the routing guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Voice Agent Linter rule with its id, title, default severity, category, what it reads (prompt, config or both) and the platforms it applies to. Filter by platform or category. Static reference, no network access.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Only rules in this category. | |
| platform | No | Only rules that apply to this platform: vapi, retell, elevenlabs or openai_realtime. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld=false, so the safety profile is covered; the description's 'Static reference, no network access' is corroborating but redundant. It does add value by enumerating the returned fields (reads targets, platforms), which matters given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no waste; the returned-field enumeration is front-loaded and the filtering/no-network notes follow compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only reference lister with no output schema, the description fully covers what is returned and how to filter, and annotations cover safety. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters fully documented and enum-constrained, so the schema already does the heavy lifting. The description's 'Filter by platform or category' restates the params without adding syntax or format detail beyond them — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (Voice Agent Linter rule) and enumerates the fields returned (id, title, severity, category, reads, platforms). This clearly distinguishes it from lint_voice_agent (which runs checks) and explain_lint_rule (which elaborates on one rule).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives some usage context ('Filter by platform or category', 'Static reference, no network access') but never states when to reach for this versus explain_lint_rule or lint_voice_agent. The reference use is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
lint_voice_agent1 field changedInput schema / properties / config_json / descriptionPrevious value: -"The agent’s config as a JSON string, exactly as the platform exports it: a Vapi assistant, a Retell agent and/or LLM (or {\"agent\": ..., \"llm\": ...}), an ElevenLabs agent, or an OpenAI Realtime session or session.update event."New value: +"The agent’s config as a JSON string, exactly as the platform exports it (remove keys first; any left are stripped before checking): a Vapi assistant, a Retell agent and/or LLM (or {\"agent\": ..., \"llm\": ...}), an ElevenLabs agent, or an OpenAI Realtime session or session.update event."explain_lint_rulelint_voice_agentlist_lint_rulesTest the voice agents you run: scored transcripts, pass/fail verdicts, latency and WER metrics.
Statically audits MCP tool surfaces for token cost, schema quality, and design issues.
Find your AI agent's likely failure mode, get runtime settings, and clarify ambiguous prompts.
Deterministic preflight checks for credentials, fund transfers, writes, and prompt overrides.
Add one secure layer between your agents and this server.
