Check documents against rules taken from the law itself. Every finding cites the exact clause.
Scored across 7 tools
Each tool maps to a distinct resource and action across the lifecycle (list → build → build-status → coverage → query → verify → verify-status). The two status pollers are cleanly separated by domain noun (get_pack_build_status vs get_verification_status), and the two paid async starters are distinguished by their purpose (build vs verify). No realistic misselection.
All tools use snake_case with a consistent verb_noun structure (list_packs, query_pack, verify_document, start_pack_build, get_pack_build_status). Multi-word nouns like pack_build_status and pack_coverage are predictable extensions of the same convention.
Seven tools is well-scoped for a pack build/query/verification service, with each tool earning its place. No redundancy or filler.
The surface covers the full core lifecycle: listing, building, polling, coverage inspection, querying, and verification. Minor gaps exist (no cancel/abort for in-flight builds or explicit pack management like delete), but agents can work around them.
Check a durable pack-build job. Poll only while active=true. When stopped, use readiness_summary and present available_actions honestly; a usable budget pause offers use now or a separately approved finite continuation. Never restart merely because the AI client's execution window ended.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned by start_pack_build |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuine behavioral context: the poll-while-active loop, the readiness_summary handoff, and the anti-pattern of restarting a stopped build. It does not discuss rate limits or cost of polling, but goes well beyond the annotations.
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?
Front-loads the core purpose in one short sentence, then adds operational guidance in compact clauses. The final sentence is slightly dense and the budget-pause clause is verbose, but nothing is redundant.
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?
An output schema exists, so return values (active, readiness_summary, available_actions) need not be re-explained, yet the description still tells the agent how to interpret and present them honestly. Coverage is good for a single-parameter polling tool.
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?
Only one parameter with 100% schema coverage, and its description already ties job_id to the value returned by start_pack_build. The description adds nothing about job_id format or semantics, so the schema baseline of 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 ("Check") and resource ("a durable pack-build job"), which clearly separates it from start_pack_build and the other read siblings. It does not explicitly contrast itself with get_verification_status or get_pack_coverage, but the durable-job framing is distinctive enough.
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 concrete usage conditions: poll only while active=true, and when stopped switch to readiness_summary / available_actions. It also states a prohibitive condition (never restart on client execution-window end). It stops short of naming sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect readiness, source coverage and freshness before high-stakes use. Disclose incomplete or stale coverage. query_ready means usable, minimum_coverage_ready means every measured section has a rule, and fully_strengthened means every measured section is satisfied. fully_ready is legacy-compatible and is not a comprehensiveness claim.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | The Vera pack ID |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, open-world behavior, and the description adds real value beyond them: it decodes the four status semantics and warns that fully_ready is legacy-compatible and not a comprehensiveness claim. It does not mention auth needs or rate limits, but for this read-only inspection tool that gap is minor.
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?
Front-loaded with the action and the pre-use context, then the enum semantics. Every sentence carries meaning, though the chained status definitions are dense and could be slightly more scannable.
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?
An output schema exists, so return shape need not be described, and the description supplies the one thing an agent genuinely needs that structure cannot convey: what each readiness status actually means. Adequate for a single-parameter read tool, with only sibling differentiation left implicit.
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?
There is a single pack_id parameter with 100% schema description coverage, so the schema fully documents the input and the description adds nothing parameter-specific. This is the baseline 3 case where structured data does the lifting.
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 ("Inspect") and resource (readiness, source coverage, freshness of a Vera pack), and the enum definitions make it distinguishable from get_pack_build_status and get_verification_status. It does not explicitly name those siblings, so it stops short of a 5.
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 a clear trigger context ("before high-stakes use") plus an actionable directive to disclose incomplete or stale coverage. It never names a when-not condition or an alternative sibling tool, so it falls short of the explicit routing a 5 requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a run using poll_after_ms until terminal=true. Only call it clean when verdict=clean, coverage_complete=true, and result_consistent=true; otherwise follow next_action.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run_id returned by verify_document |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read profile is covered. The description adds genuinely useful behavior beyond that: this is a polling endpoint, it terminates on terminal=true, and success requires the conjunction of verdict=clean, coverage_complete=true, and result_consistent=true. It does not mention rate limits, backoff, or what happens after terminal, keeping it short of a 5.
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?
Two sentences, zero filler, front-loaded with the action and polling mechanism, then the success condition. Every clause earns its place and nothing is repeated from the schema or annotations.
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?
Given an output schema exists, the description does not need to explain return fields, and it correctly focuses on the decision logic (terminal, verdict, coverage_complete, result_consistent, next_action). For a read-only polling tool with full schema coverage and annotations, this is nearly complete; only the absence of guidance on polling cadence, timeout, or what next_action can contain keeps it from a 5.
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?
The only parameter is run_id, and the schema already documents it fully at 100% coverage (including that it comes from verify_document). The description adds the polling parameter poll_after_ms, which is behavior-adjacent rather than a declared input, but that is bonus information rather than required semantic fill-in. Baseline for a fully documented single parameter is high.
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?
The description states a specific action ('Poll a run') and names the artifact being read back ('verification run' per the title), which is enough for an agent to identify it. It does not explicitly contrast itself with siblings like get_pack_build_status or verify_document, so an agent must infer the distinction from the run_id parameter and the Vera/verification framing.
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?
It gives actionable polling guidance ('using poll_after_ms until terminal=true') and a decision rule for declaring success versus following next_action. It stops short of stating when not to call it or what the alternative tools are, so it is clear context without full exclusion logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List owned and public packs. Select from available_packs and require readiness.query_ready=true. If none fits, do not guess a pack_id: propose a finite pack plan, ask the user to approve a credit ceiling, then use start_pack_build if approved.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: a readiness gate on results and an explicit anti-hallucination guardrail ('do not guess a pack_id'). It does not discuss pagination or result volume, which keeps it below a 5.
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 sentences, front-loaded with the purpose before the workflow, and every sentence carries actionable content. The middle sentence is dense but not padded; minor tightening of the selection/readiness clause would make it a 5.
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 an output schema present, the description need not explain return values, and with no parameters there is nothing more to specify. It covers purpose, selection gate, fallback behavior, and the routing to start_pack_build, so an agent has everything required to act correctly.
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?
The tool takes zero parameters, so there is no per-parameter semantics to explain; per the rubric this yields the baseline 4. The description adds no misleading parameter expectations and correctly implies the result is a selectable set.
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 ('List owned and public packs') and goes on to route the agent toward selection logic and a fallback, which helps distinguish it from siblings like query_pack and start_pack_build. The core purpose is clear, though the routing detail is mixed into the statement rather than cleanly separated.
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 explicit selection criteria ('require readiness.query_ready=true'), an explicit exclusion ('do not guess a pack_id'), and the exact next tool to use if nothing fits ('use start_pack_build'), including the approval precondition of a credit ceiling. This is about as complete as when-to-use guidance gets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the best matching locked rules and exact evidence from a query-ready Vera pack. This costs credits. Preserve each verified quote and citation, distinguish them from your inference, and treat coverage=none as no answer.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | The Vera pack ID (from list_packs) | |
| question | Yes | The question to ask |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false, and the description is consistent with that. The description adds real context beyond the annotations: credit consumption, the meaning of coverage=none (no answer), and an instruction to preserve verified quotes and separate them from inference.
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 short sentences with the core action front-loaded, followed by the cost warning and the output-handling rules. Every sentence carries distinct information and there is no padding.
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 an output schema present, return-value explanation is unnecessary, and the description covers the non-obvious operational facts (cost, coverage=none semantics, quote fidelity). It stops short of spelling out how to obtain a query-ready pack, which would fully close the loop with the build siblings.
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% for both parameters (pack_id pointing back to list_packs, question with length bounds), so the schema carries the parameter burden. The description adds no format or syntax detail beyond what the schema already provides, making the baseline 3 correct.
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 (retrieve) and a precise resource ('best matching locked rules and exact evidence'), plus the qualifier that the pack must be query-ready. This distinguishes it from siblings like start_pack_build, get_pack_build_status, and verify_document without needing to name them.
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?
Implies the prerequisite that the pack must be 'query-ready' and warns that the call 'costs credits', but gives no explicit when-to-use/when-not guidance and never names an alternative tool. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a paid asynchronous pack build after the user explicitly approves max_credits. Supply exactly one of pack_id (an owned AI-buildable pack) or new_pack. The response returns immediately with job_id; poll get_pack_build_status only while active=true. max_credits is a hard ceiling, not a promised final charge. Reuse idempotency_key only for an exact retry.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | No | An existing owned AI-buildable pack; mutually exclusive with new_pack | |
| new_pack | No | A new Vera pack to create; mutually exclusive with pack_id | |
| max_rounds | No | Maximum strengthening rounds; normally 3 | |
| max_credits | Yes | Hard credit ceiling explicitly approved by the user for this build job | |
| idempotency_key | Yes | Required retry key; reuse only for this exact build request |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it as a mutating, open-world, idempotent, non-destructive operation, and the description is consistent with that while adding context the annotations cannot carry: the async return of job_id, the polling lifecycle, the fact that max_credits is a hard ceiling rather than a final charge, and the idempotency_key retry rule. Billing and retry semantics are exactly the behavioral detail an agent needs before committing a paid job.
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?
Four dense sentences with zero filler, front-loaded with the action and its precondition. Each sentence carries a distinct, non-redundant constraint (approval, mutual exclusivity, async polling, ceiling semantics, retry key).
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 paid asynchronous mutation tool with a nested object parameter, the description covers approval requirements, input constraints, return behavior, polling, and retry semantics. An output schema exists, so return values need not be spelled out, and the description still notes the immediate job_id response.
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 baseline is 3, but the description adds real meaning beyond the schema by clarifying that max_credits is a ceiling and not a promised final charge, and by restating the pack_id/new_pack mutual exclusivity as an invocation rule. It does not add syntax or format guidance for max_rounds or intention beyond what the schema already supplies.
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?
The opening sentence names a specific verb and resource ('Start a ... pack build') and qualifies it as paid and asynchronous, which immediately separates it from the read-only siblings. It also notes exactly what is being created (a new pack or a build of an existing one), so an agent can distinguish it from get_pack_build_status without opening the 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?
States the precondition for use ('after the user explicitly approves max_credits'), the input constraint ('supply exactly one of pack_id or new_pack'), and routes to the sibling tool with its own condition ('poll get_pack_build_status only while active=true'). This is explicit when-to-use plus a named alternative, which is the top of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a paid, asynchronous check against a query-ready pack. Use one unique idempotency_key and reuse it only for an exact retry. Omit mode to use the pack's mode. Poll get_verification_status until terminal=true.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional mode override; normally omit this | |
| pack_id | Yes | The Vera pack ID to verify against | |
| document_text | Yes | The full document text; whitespace does not count toward the minimum | |
| idempotency_key | Yes | Required retry key. Reuse only for this exact pack, document, and mode. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds materially new context they do not: the operation is paid, it is asynchronous, and the caller must poll a separate tool for terminal status. Cost disclosure and the async+polling contract are exactly the kind of traits annotations cannot express.
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, each earning its place: what the call is and costs, the idempotency contract, the mode default, and the required follow-up. The most decision-relevant facts are front-loaded with zero 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?
An output schema exists, so return values need not be described, and the description correctly points to the polling tool for terminal status. Combined with full schema coverage and annotations, an agent has everything needed to invoke this correctly, including cost and prerequisite context.
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 baseline is 3. The description's guidance on idempotency_key reuse and omitting mode largely restates what the schema already documents ('Reuse only for this exact pack, document, and mode' / 'normally omit this'), adding little beyond the structured fields.
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 (verify a document against a query-ready pack) plus the key behavioral traits (paid, asynchronous). It distinguishes itself from siblings by naming get_verification_status as the polling companion, so an agent can route between this and the status tool without opening either 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 operational guidance: one unique idempotency_key reused only for exact retries, omit mode to inherit the pack's mode, and poll get_verification_status until terminal=true. The prerequisite 'query-ready pack' is implied as a gating condition, but there is no explicit when-not guidance (e.g., behavior against an unbuilt pack).
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.
get_pack_build_statusget_pack_coverageget_verification_statuslist_packsquery_packstart_pack_buildverify_document
Add one secure layer between your agents and this server.