Voice Agent Linter

Lint a voice agent

lint_voice_agent

Read-onlyIdempotent

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.

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

changedInput schema / properties / config_json / description

Previous 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."

First observedOct 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Voice Agent Linter tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?