Server Quality Checklist

Tool Scores

• vorion_gate_actionA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses return fields (allowed, current tier, required tier, reason) and frames the tool as a pre-flight check, implying no side effects. But it does not discuss error conditions, permissions, or whether any state is modified, leaving gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences: first states purpose, second covers return values and usage. No wasted words, front-loaded with the core question.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple authorization check with fully documented schemas, the description provides essential context: purpose, return values, and usage scenario. It lacks error handling details but is sufficient for an agent to invoke correctly.

  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?

  The input schema already documents all three parameters with descriptions (100% coverage), so baseline is 3. The description reinforces the meaning of requiredTier by mentioning 'required tier' but adds no additional syntax or format details beyond the schema.

  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?

  The description clearly states the tool checks if an AI agent is allowed to perform a specific action based on trust tier. It uses a specific verb ('Check'), names the resource ('specific action'), and differentiates from sibling vorion_check_trust by focusing on action-level authorization with required tier comparison.

  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?

  Explicitly says 'Use this as a pre-flight check before executing sensitive operations', providing clear when-to-use guidance. However, it does not mention alternatives or exclusions, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_tenant_audit_tailA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description adds valuable behavioral context: events carry hash-chained provenance (eventId, priorProofHash, proofHash) and default to the caller's tenant. It implies a non-mutating read via 'tail,' but does not explicitly state its read-only nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place: purpose, a key output characteristic, and usage scenarios. It is front-loaded and free of fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter tool with no output schema, the description provides enough context for an agent to understand what the tool does, when to use it, and a key detail of the returned events. It could explicitly confirm the response shape, but the mentioned fields (eventId, priorProofHash, proofHash) suffice.

  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%, with clear descriptions for both 'limit' (with min/max/default) and 'tenantId' (defaults to caller's tenant). The description adds no new parameter-specific info beyond what the schema already provides, so the baseline of 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?

  The description clearly states the tool 'Tail the most recent audit events for a tenant' with a specific verb and resource, and notes the default caller's tenant. This distinguishes it from sibling tools like vorion_record_signal or vorion_gate_action, which are mutation-focused.

  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?

  Explicit use cases are given: 'verify governance activity is being recorded correctly' or 'surface the live audit stream in a dashboard / glass window.' This provides clear context, though it does not explicitly name alternative tools or state when NOT to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_check_trustA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden. It clearly indicates this is a lookup operation ('Look up', 'Returns') and discloses the exact output fields: numeric score, tier number, tier name, and observation tier. This is transparent for a read-only tool, though it does not discuss authentication, staleness, or error behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action and resource, and every sentence adds value. The return fields and use case are included without unnecessary elaboration.

  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?

  Despite having no output schema, the description fully enumerates the return values (score, tier number, tier name, observation tier) and explains the operational context. Given the simple single-parameter schema and clear sibling context, the description is complete for an agent to select and invoke the tool correctly.

  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 coverage is 100% because the only parameter, agentId, is described as 'Unique identifier of the agent to look up.' The description adds no additional semantic information beyond what the schema already provides, so the baseline of 3 is appropriate.

  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?

  The description opens with a specific verb and resource: 'Look up an AI agent's current trust score and tier in the Vorion governance system.' It clearly distinguishes this from sibling tools by focusing on a read-only trust lookup, whereas siblings like record_signal or gate_action imply writing or enforcement.

  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?

  The description gives an explicit use case: 'Use this to check how trusted an agent is before allowing it to perform sensitive actions.' This provides clear context for when to invoke the tool, though it does not mention alternatives or explicit when-not-to-use conditions, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_log_proofA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It explicitly states the audit trail is immutable and hash-linked, and reveals that it returns a proof hash and chain length for verification. This goes beyond basic operation description, though it doesn't cover error cases or constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loading the primary purpose, then detailing the content and return value. Every sentence earns its place with no filler or redundancy.

  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?

  For a simple logging tool with fully described parameters and a clear return value, the description covers all necessary aspects. It explains both the operation and its output, and the absence of an output schema is mitigated by the explicit mention of the proof hash and chain length.

  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?

  The schema description coverage is 100%, so the schema already explains all four parameters. The description adds minimal extra semantic value by naming 'agent ID, action, and reasoning,' but does not deepen understanding beyond what the schema provides. Baseline 3 is appropriate.

  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?

  The description clearly states the tool logs governance decisions to an immutable proof chain, specifies the decision types (ALLOW/DENY), and lists the recorded data. This distinguishes it from sibling tools like vorion_tenant_audit_tail or vorion_record_signal, though it could be more explicit about those distinctions.

  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?

  The description clearly implies when to use it (whenever a governance decision is made) but does not explicitly mention when not to use it or name alternative tools. This is a clear context without exclusions, so it earns a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_record_signalA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the burden of behavioral disclosure. It goes beyond a simple 'record' by explaining the consequence: positive signals increase trust over time, while negative signals decrease trust, with higher-tier agents penalized more severely per the formula P(T) = 3 + T. This is useful behavioral context, though it omits details like authentication, rate limits, or return values.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long, with the core action front-loaded in the first sentence. Each subsequent sentence adds meaningful context (positive/negative impact, penalty formula) without any fluff or repetition. It is concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose and behavioral consequences, but it is incomplete in operational details. Since there is no output schema, the description should have specified what the caller receives (e.g., confirmation, updated trust score, or error behavior). It also omits prerequisites (e.g., whether the agent must exist) and idempotency characteristics. This is a moderate gap for a recording tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all three parameters, so the baseline is 3. The description adds extra semantic value by mapping the type enum values (behavioral.success, compliance.pass) to positive signals and (behavioral.failure, compliance.fail) to negative signals, and by explaining the penalty formula that relates to the type/value choice. This enriches the schema's bare descriptions.

  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?

  The description opens with a specific verb and resource: 'Record a behavioral signal (positive or negative) for an AI agent.' It immediately distinguishes itself from sibling tools like vorion_check_trust (which presumably reads trust) and vorion_log_proof (which logs proofs) by focusing on recording behavioral signals and their trust impact.

  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?

  The description provides clear context on when to use the tool by explaining that positive signals (success, compliance pass) increase trust and negative signals (failure, compliance fail) decrease trust. However, it does not explicitly mention alternatives or exclusions, so it stops short of the full 'when-to-use vs when-not-to-use' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_canary_submitA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses key behavioral consequences: results feed the tenant's behavioral baseline, repeated ambiguous outcomes can trigger AUDITED state, and it returns a proofHash for chain verification. This goes beyond basic write semantics, though it omits permission requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the main action, and each sentence adds value: definition, consequences, and return value. No redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 5 parameters (including a nested evidence object) and no output schema, but the description covers the core purpose, outcome semantics, side effects, and return value. It could mention error conditions or the evidence parameter, but the schema already describes fields. Overall, sufficient for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that pass/fail/ambiguous outcomes feed the baseline and can trigger AUDITED state, giving semantic weight to the outcome enum. It also ties probeId to the canary probe concept.

  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?

  The description clearly states the verb ('Submit a canary probe result') and the specific resource ('Cognigate Runtime'). It explains what canary probes are and how results are classified, distinguishing this from sibling tools like vorion_record_signal or vorion_log_proof. The purpose is unambiguous.

  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?

  The description provides clear context on when to use this tool: when submitting canary probe results after running adversarial/behavioral tests. It explains the outcome classifications and their consequences. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to select it over siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_health_checkA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the transparency burden. It discloses the response contents (status, uptime, dependency state) and the tool's non-destructive, informational nature. It lacks details on error handling or auth, but for a simple health check this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the core action and purpose. Every phrase adds value: 'pre-flight check,' 'returns status,' and 'confirm reachable' are all useful.

  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 parameters and no output schema, the description covers everything essential: what the tool does, when to use it, and what it returns. It is complete for a simple health check tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description needs no parameter details. Baseline 4 applies, and the description correctly omits irrelevant parameter information.

  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?

  The description clearly states the action ('Hit the health endpoint'), the resource ('Cognigate Runtime'), and the return value ('status, uptime, dependency state'). It is distinct from sibling governance tools, which involve trust checks, signals, and actions.

  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?

  Provides explicit when-to-use: 'pre-flight check before relying on remote governance operations' and 'confirm the deployed API is reachable.' Does not explicitly state when-not-to-use or name alternatives, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_tenant_listA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries full burden. It discloses admin-only access, the API key requirement via VORION_API_KEY, and the exact return fields. It does not mention rate limits, pagination, or error behavior, but covers the most relevant behavioral traits for a list operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four short sentences, each adding value: purpose, access restriction, return contents, and authentication method. There is no redundancy or filler.

  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?

  For a simple zero-parameter tool with no output schema, the description is complete: it explains what it does, who can use it, what it returns, and how to authenticate. Lacking pagination details is not critical for a tenant list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the description correctly avoids parameter detail. With 100% schema coverage trivially satisfied, the baseline 4 for zero-parameter tools 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?

  The description uses the specific verb 'List' with the resource 'all tenants' on the 'Cognigate Runtime', clearly distinguishing it from sibling tools like vorion_tenant_whoami (single tenant) and vorion_tenant_audit_tail (audit logs).

  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?

  The description clearly states 'Admin-only' and 'Requires an admin-role API key', giving explicit access context. It does not name alternatives or exclusions, but the scope 'all tenants' implies enumeration, differentiating it from other tenant-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_tenant_whoamiA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden. It discloses that the tool resolves the API key, returns specific fields (tenant id, role, capabilities), and requires the VORION_API_URL and VORION_API_KEY env vars. This adds meaningful context. It does not explicitly state whether it is read-only or describe error handling, but for a simple lookup tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with purpose and return values, followed by usage guidance and requirements. Every sentence adds value; no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, when to use it, required environment variables, and return values (tenant id, role, capabilities). With no output schema, this is sufficient. It could add error scenarios or explicit read-only confirmation, but overall it is complete for the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the baseline is 4. The description goes further by explaining that the tool uses the calling API key and requires specific environment variables, adding meaningful operational context beyond the empty schema.

  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?

  The description clearly states the tool resolves the calling API key against the Cognigate Runtime and returns the tenant id, role, and capabilities. It is specific and distinct from sibling tools like vorion_tenant_list, which lists tenants, whereas this tool identifies the current session's tenant context.

  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?

  The description explicitly advises 'Use this first if you need to confirm which tenant context the MCP session is running in', giving a clear when-to-use scenario. However, it does not mention when not to use it or alternative tools, so it stops short of full alternatives coverage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vorion_execute_governedA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the atomic operation, the conditional execution, the recording of behavioral signals, and the logging of proof. It also describes the return value (governance trail) including gate decision, execution result, trust delta, and proof hash.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loads the core function ('Gate + execute + log in one atomic call'), and every sentence adds value: the flow, the return, and the usage recommendation. It is concise and well-structured.

  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?

  Despite having no output schema, the description explains the return value comprehensively. It covers the full operation flow, atomicity, and the recommended usage. The parameter details are already in the schema, and the description provides sufficient context for the agent to use the tool correctly.

  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?

  Input schema coverage is 100%, with each parameter having a clear description (e.g., 'Risk level', 'Action to perform'). The description does not add additional parameter semantics beyond what the schema already provides, so the baseline of 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?

  The description clearly states what the tool does: 'Gate + execute + log in one atomic call.' It specifies the exact steps (check trust, execute if allowed, record signal, log proof) and distinguishes itself from sibling tools by combining their functions. This is a specific, well-defined purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'This is the recommended way to run governed tool calls' and states it 'replaces manual check-then-execute patterns,' giving clear guidance on when to use it and positioning it against manual alternatives. This provides strong usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.