AxioRank — Agent Firewall

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

The description goes beyond annotations by explicitly stating that the detector is saved disabled for review and that 'An LLM never arms detection unattended.' This addresses safety and behavioral traits not covered by annotations, which indicate it is a mutation (readOnlyHint=false) but not destructive (destructiveHint=false). The description clarifies the output state and responsible use.

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 description is three sentences with no fluff. The first sentence communicates the core action, the second addresses safety, and the third lists requirements. It is front-loaded and efficient.

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 single-parameter tool with no output schema, the description covers all necessary context: input expectation, output behavior (saved disabled), allowed categories, required permissions, and plan tier. It is complete for an agent to correctly invoke the 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?

Schema coverage is 100% with a clear parameter description. The tool description adds minimal extra meaning about the parameter, only reinforcing that the input should be a plain English risk description. Baseline of 3 is appropriate.

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 clearly states the action: accepts a risk description in plain English, generates a custom content detector (regex or keyword), and saves it disabled for review. The title aligns with this. Among sibling tools, none duplicate this functionality, so it is well-differentiated.

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 description specifies when to use (for outbound content categories like secret/pii/destructive/injection/egress) and the prerequisites (policies:write scope, AI-assessments-enabled plan). It implies the tool is for creation only, not for enabling detectors. However, it does not explicitly state when not to use or provide alternative tools, which is acceptable given no siblings offer similar functionality.

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

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

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) are supplemented by description details: blocking briefly, returning pending status for retry, and auth scope. No contradictions.

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 front-loaded sentences: the first states the purpose, the second adds behavioral and auth details. No redundant words.

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?

The description covers the polling workflow, auth, and retry guidance. Without an output schema, it could mention the return format more explicitly, but it is sufficient for a simple read operation.

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 single parameter approvalId has full schema description (100% coverage) explaining its origin. The tool description only repeats that same info, adding no new semantics beyond the schema.

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 specifies the verb 'poll' and the resource 'verdict of a held tool call', clearly distinguishing it from sibling tools which handle other operations like author detection, agent creation, etc.

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 description tells the agent to pass the approvalId from axiorank_score_tool_call, explains polling behavior, and notes auth requirements (gateway:write scope and same agent key). It lacks explicit when-not-to-use or alternatives but is otherwise clear.

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

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

Annotations provide minimal behavioral hints (readOnlyHint=false, etc.). The description adds meaningful context: no durable secret is emitted, token is short-lived, and the return value is a bootstrap token. It goes beyond annotations by describing the auth implications.

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, front-loaded with the primary action and key constraint (short-lived token). Every sentence adds value without redundancy. Highly efficient.

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?

The description covers the creation action, return value (bootstrap token), auth requirement, and token lifetime context. No output schema exists, so the description adequately explains the output. Parameter details are lacking but schema covers some. Overall sufficient for a creation 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?

Schema description coverage is 40% (only ttlSeconds and tokenScopes have descriptions). The tool description does not elaborate on parameters like name, labels, or description beyond what the schema provides. No additional semantic guidance is given for these inputs.

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 clearly states the verb 'create' and the resource 'agent', and specifies the output is a short-lived bootstrap token. It distinguishes from siblings like axiorank_get_agent (read-only) and axiorank_issue_token (token issuance). The title is aligned and unambiguous.

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?

Explicitly mentions required scope `agents:write` and provides guidance for long-term auth (add static key or federation binding in dashboard). Does not explicitly state when not to use or alternatives among siblings, 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.

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It reveals that policies are created disabled to prevent unattended enforcement, which adds significant safety context. However, it does not disclose side effects like idempotency 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.

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

The description is a single, efficient paragraph of about 60 words. It front-loads purpose and safety, then workflow, then param details. It is concise but could benefit from bullet points for clarity.

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 the complexity of governance policy creation with 7 parameters, no output schema, and a rich context structure not explained, the description is incomplete. It should cover the context object, priority, riskThreshold, and signalCategory to be fully useful.

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 0%, so the description must compensate. It explains toolPattern (glob) and action (enum values) but fails to explain context, priority, riskThreshold, or signalCategory. With 7 parameters and no schema descriptions, this is a major gap.

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 clearly states 'Create an outbound governance policy' and emphasizes it is created disabled, which is a specific verb+resource combination. It distinguishes from siblings by referencing axiorank_get_policy and axiorank_update_policy.

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 description explicitly outlines a workflow: create, then review with axiorank_get_policy, then enable with axiorank_update_policy. It also mentions the required scope 'policies:write'. It does not provide explicit when-not-to-use scenarios but the disabled nature implies caution.

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

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

Annotations declare read-only and idempotent; description adds workspace scoping and specific posture fields, enhancing behavioral context without contradicting 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?

Two sentences, no redundant words, front-loaded with purpose and key details.

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?

Despite no output schema, description lists return fields (posture components) and parameter source, fully covering the tool's operation for a simple read 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?

Single parameter 'agentId' fully described in schema with pattern and a cross-reference to axiorank_list_agents, adding meaningful context beyond the schema.

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?

Description clearly states 'Fetch one agent's posture' with specific fields (quarantine state, labels, last-used, revocation), distinguishing it from list and mutation siblings.

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?

Indicates scope ('scoped to your workspace') and required scope ('agents:read'), providing clear context for when to use, though no explicit exclusions or alternatives.

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

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

Annotations already provide read-only, idempotent, and non-destructive hints. The description adds useful context about what exactly is probed (API and DB reachability) and the return format, going beyond 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?

Extremely concise: two sentences provide all necessary information without redundancy. Front-loaded with the core purpose.

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 simple health check tool, the description covers the purpose, what it checks, and the return format. No output schema is needed given the simplicity.

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 are no parameters, so the description needs no parameter details. The baseline score for zero parameters is 4, and the description does not detract.

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 clearly identifies the tool as a liveness/readiness probe for the control plane, specifying it checks API and database reachability and returns a status field. This distinguishes it from sibling tools which focus on agents, policies, incidents, etc.

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 description states this is a health probe, which implicitly indicates when to use it (e.g., before other operations). While it doesn't explicitly list exclusions, the context is clear and no alternatives are needed for this simple check.

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

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

The description adds significant behavioral context beyond annotations: it explains what the tool returns (kill-chain finding or null), mentions the scope requirement, and describes the content of the finding. Annotations already declare readOnlyHint, idempotentHint, etc., but the description enriches understanding with specific details.

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 description is concise (two sentences), front-loaded with the main action, and contains no unnecessary words. Every sentence adds value.

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 the tool's simplicity (one parameter, no output schema), the description is complete. It explains the return value, null case, and required scope, which is sufficient for an agent to understand and invoke the tool 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?

Schema description coverage is 100%, and the schema already describes the alertId parameter clearly (UUID format and origin). The description does not add additional parameter-level information beyond the schema.

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 clearly states it fetches kill-chain evidence for an alert, listing the elements (multi-step attack pattern, severity, tool-call ids). It distinguishes from sibling tools like 'axiorank_list_incidents' by focusing on detailed evidence retrieval.

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 description provides clear context for when to use the tool (fetching kill-chain evidence) and mentions null return for non-kill-chain alerts. It also specifies the required scope ('logs:read'). However, it does not explicitly mention alternatives or cases where the tool should not be used.

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

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

The description adds behavioral context beyond annotations by stating the tool is 'scoped to your workspace' and requires a specific OAuth scope. Annotations already declare it as read-only, idempotent, non-destructive, so the description complements well without contradiction.

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 description is extremely concise (two sentences, 18 words), front-loading the core purpose ('Fetch one outbound policy by id') and adding the scope requirement without extraneous detail.

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 the tool's simplicity (single param, read-only fetch), the description is complete enough. It covers what is fetched (policy), how to identify it (by id), and constraints (scoped to workspace, auth scope). No output schema exists, but for a basic fetch tool, finer details about response structure are not critical.

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?

With 100% schema coverage, the baseline is 3. The schema's description for `policyId` already explains it's 'The policy's UUID (from axiorank_list_policies).' The tool description adds no further meaning to the parameter semantics.

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 clearly states the verb 'Fetch', the resource 'one outbound policy', and the identifier 'by id'. It distinguishes from sibling tools like axiorank_list_policies (list) and mutation tools, making purpose unambiguous.

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 description mentions the required scope 'policies:read', setting an explicit prerequisite. While it doesn't explicitly state when not to use it, the context from sibling names (e.g., axiorank_list_policies, axiorank_create_policy) provides implicit guidance for appropriate usage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral detail: returns protocols grouped into six planes with coverage status and direction, which goes 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?

Two sentences, zero wasted words. First sentence defines the tool's output, second gives a concrete use case. Front-loaded and efficient.

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 no output schema, the description explains the grouping and attributes well. The ellipsis implies more protocols exist, but the core structure is clear. Could be slightly more explicit about the six planes, but still complete enough for a discovery 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?

No parameters, schema coverage 100%. The description explains the output structure (planes, status, direction) which is necessary since there is no output schema. Baseline 4 is appropriate.

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 clearly states it lists agent-interop protocols AxioRank can govern, with specific examples (A2A, MCP, etc.), and distinguishes from sibling tools which focus on agents, policies, or incidents.

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?

Explicitly says to use before wiring up card verification or inbound bot management, providing clear context. Does not explicitly state when not to use, but the sibling tool set makes it obvious this is the only protocol discovery tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the required scope and confirms it reports usage data, providing useful context beyond 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?

Two efficient sentences: first describes purpose and outputs, second adds scope requirement. No redundant information.

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 parameterless, read-only tool, the description fully enumerates the returned data (plan tier, governed events vs limit, ML assessments). No output schema needed.

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?

No parameters exist, so schema coverage is 100%. The description does not need to explain parameters. Baseline 4 is appropriate.

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 clearly states the verb 'Report' and the resource 'usage & plan', listing specific outputs (plan tier, governed events vs monthly limit, ML assessments). No sibling tool overlaps with this billing focus, so it distinguishes well.

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?

Explicitly requires 'logs:read' scope, which guides authentication. Context implies it's for workspace billing usage, but no explicit 'when not to use' or alternatives are given.

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

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

Discloses expiration within hour, non-replayability, and scope requirement. Annotations provide no contradictory signals and description adds value beyond 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?

Four concise sentences, front-loaded with key action, no wasted words.

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?

Description explains token nature and constraints but does not mention return format or error cases. With no output schema, this is a moderate gap.

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 covers all parameters with descriptions (100% coverage). Description adds context about token usage but no specific parameter semantics beyond schema.

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?

Description clearly states it mints a short-lived token for an agent, uses specific verb 'mint', specifies token prefix `axr_tok_…`, and distinguishes from durable keys issued in dashboard.

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 when to use (zero-trust auth for agents) and when not (durable keys elsewhere). Mentions required scope `keys:write`. Could explicitly contrast with sibling tools like revoke_agent, but no direct alternative among siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds scope requirement and specifies returned fields, which adds value beyond 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?

Two sentences efficiently convey purpose, output, usage guidance, and auth requirement. No wasted words.

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?

No output schema, but description explains what is returned (id, name, labels, quarantine, last-used status). Covers active agents, scope requirement, and usage context. Complete for a simple list 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?

No parameters exist; schema coverage is 100% (empty schema). Description adds nothing about parameters, but baseline for 0 params is 4. No additional param info needed.

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 clearly states it lists active agents with specific fields (id, name, labels, quarantine, last-used status). The verb 'List' and resource 'active agents' are specific. This distinguishes it from siblings like axiorank_get_agent.

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?

Explicitly says 'Use this to find an agent's id before calling agent-specific tools,' providing clear context for when to use. Also mentions required scope 'agents:read'. Does not include explicit when-not or alternatives, but the guidance is strong.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the description adds value by explaining the ordering (newest first) and filterable fields. No contradictions with 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?

The description is a single sentence with key information, followed by a scope requirement. No wasted words, clearly structured.

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 list tool with 4 optional parameters and no output schema, the description covers filtering, ordering, and scope. It does not mention pagination or response structure, but these are somewhat implied by tool type. Adequate for the complexity.

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 0%, so the description must compensate. It lists three filterable parameters (status, severity, kind) with their enum values, but does not describe the 'limit' parameter. This adds some meaning beyond the schema but is incomplete.

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 clearly states the tool lists security alerts/incidents, specifies ordering (newest first), and lists filterable attributes (status, severity, kind). This distinguishes it from siblings like get_incident which retrieves a single incident, and other list tools.

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 description mentions required scope 'logs:read', providing a usage prerequisite. However, it does not explicitly guide when to use this tool versus alternatives like get_incident or search_audit_logs, though the context implies it for listing multiple incidents.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds behavioral details: lists 'most recent' assessments, includes specific fields, and requires a scope. No contradictions.

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, no wasted words. The first sentence states the purpose and output fields; the second adds the required scope. Efficient and front-loaded.

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 simple list tool with one optional parameter and no output schema, the description covers purpose, output fields, and scope. It could mention ordering or pagination more explicitly, but it's mostly complete.

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 0%, and the description does not mention the limit parameter. Although the schema provides default and bounds, the description fails to explain its purpose or usage, leaving a gap for the agent.

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 clearly identifies the tool as listing ML/LLM threat assessments, specifying the kind of data included (model verdict, threat class, confidence, recommendation) and scope (tool calls and cards). This differentiates it from sibling list tools like list_agents or list_incidents.

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 description states a required scope (logs:read) and implies usage for retrieving recent assessments, but lacks explicit guidance on when not to use it or alternatives. Despite this, the context is clear for an agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the required 'policies:read' scope and detailing the returned fields, which provides behavioral context 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?

The description is two sentences: the first covers purpose and output, the second adds the authorization requirement. No redundant or extraneous information; efficiently front-loaded.

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 no parameters, no output schema, and comprehensive annotations, the description is mostly complete. It could mention pagination or limits, but for a simple list tool this is sufficient.

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 are no parameters, so schema coverage is 100%. The baseline for zero parameters is 4; the description adds no parameter info (unnecessary) and does not detract.

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 clearly specifies the verb 'list' and the resource 'outbound governance policies', including the specific fields returned (tool pattern, action, risk threshold, priority, enabled flag). It distinguishes from siblings like 'get_policy' (single) and 'create_policy' implicitly by focusing on listing.

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 description states the tool lists policies in the workspace but does not provide explicit guidance on when to use this tool versus alternatives like 'get_policy' or 'create_policy'. It mentions the required scope but lacks when-not-to-use or contextual decision-making hints.

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

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

Annotations already convey readOnly and idempotent hints. The description adds behavioral context: the output includes aggregated counts with k-anonymity gating, and it is a shared feed. No contradictions with 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?

The description is two concise sentences: the first covers purpose and output, the second clarifies scope and access. Every sentence adds value with no redundancy.

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 tool with 0 parameters and no output schema, the description adequately explains the output's nature (aggregate counts) and data scope. It could be enhanced by detailing the output structure (e.g., fields returned), but overall complete.

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?

No parameters exist, and schema coverage is 100% by definition. The description does not add parameter details, which is expected. Baseline score of 3 is appropriate.

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 clearly states the verb 'List' and the resource 'external identities flagged across the AxioRank network', with specific output detail (k-anonymity-gated aggregate counts). This purpose is unique among siblings like axiorank_list_agents and axiorank_list_incidents.

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 description notes this is the 'shared cross-tenant feed, not your private data' and requires 'logs:read' scope, providing context on when to use. However, it does not explicitly name alternative tools or state when not to use.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable context: it explains the mechanism (denying all tool calls) and confirms reversibility. No contradiction with annotations; the description complements them.

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 description is two sentences, highly concise, with the key action stated first. Every word serves a purpose, making it easy to parse quickly.

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 the tool's simplicity (2 parameters, no output schema, clear annotations), the description covers purpose, effect, scope, reversibility, and provides an example. It leaves no ambiguity for an AI agent.

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 coverage is 100%, so parameters are well-documented. The description adds a specific usage hint ('Set quarantine: false to restore'), which aids understanding beyond the schema. This justifies a score above the baseline of 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?

The description clearly states the verb (quarantine/release) and the resource (agent), using the phrase 'Reversible kill switch' to emphasize the action. It distinguishes from sibling tools like axiorank_revoke_agent (permanent) by noting reversibility.

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 description explicitly states the required scope ('agents:write') and the effect (DENIES all tool calls). While it does not directly compare to alternatives, the phrase 'Reversible kill switch' implies temporary use vs permanent revocation, providing context for when 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.

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

Annotations indicate destructive and idempotent. Description adds: keys stop immediately, irreversible, audit kept. No contradiction with 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?

Three sentences that are front-loaded and each adds value: purpose, effects, scope, alternative. No unnecessary words.

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 the tool's simplicity (one param, no output schema), the description covers all necessary aspects: purpose, behavior, limitations, and scope. No gaps.

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 has 100% coverage for the single parameter, so baseline 3. Description does not add extra parameter semantics beyond what the schema's description already provides.

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 uses the specific verb 'revoke' and the resource 'agent', and distinguishes from the sibling 'axiorank_quarantine_agent' by noting it is permanent. The title and description align clearly.

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?

Explicitly states when to use (incident response, permanent revocation) and when not to (prefer quarantine for reversible pause). Also mentions required scope 'agents:write'.

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

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

The description adds significant behavioral context beyond annotations: it discloses what checks are performed (secrets, PII, destructive ops, prompt-injection, egress), that it applies policies, records audit logs, and returns a decision. Annotations indicate non-read-only and non-idempotent, but description confirms it's a safety gate without contradicting.

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 description is extremely concise at two sentences, front-loading the core action and following with workflow guidance. Every sentence adds value without redundancy or unnecessary detail.

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 the complexity of 11 parameters and no output schema, the description covers the essential decision outcomes (allow, deny, hold) and ties to approval polling. It lacks return structure details (e.g., score field), but the description is sufficient for basic usage flow.

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 0%, yet the description does not explain any of the 11 parameters beyond implying the 'tool' field identifies the call being inspected. It does not clarify fields like 'context', 'arguments', 'phase', 'intent', or how they relate to the scoring. This forces the agent to infer from names alone, which is insufficient.

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 clearly states the tool's purpose: inspecting a proposed agent tool call before execution. It specifies the actions (scoring risk, content inspection, policy application, audit logging) and the return decision (allow, deny, hold). This distinguishes it from siblings like axiorank_check_approval and axiorank_get_incident.

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 description provides explicit usage guidance: call this before executing tool calls in the tool-use loop, and refuse or wait on non-allow decisions. It also mentions the sibling tool axiorank_check_approval for polling approval status on hold, giving clear when-to-use and alternatives.

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

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

Annotations already declare read-only, idempotent, non-destructive. The description adds that payloads are secret-redacted and ordering is newest-first, which goes beyond annotations. Could mention pagination or rate limits, but overall good.

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 clear sentences plus an example. No redundant words. Front-loaded with purpose. Highly efficient.

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?

No output schema is provided, and the description does not mention return fields, pagination, or how results are structured. It covers ordering, redaction, and auth scope, but for a search tool with 8 parameters, more detail on output behavior is expected. Limits are mentioned in schema but not in description.

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 low (38%, only 3 of 8 parameters have descriptions). The description names the filters (decision, source, agentId, tool, minRisk, time window) but does not detail each parameter's semantics. The example and naming add some value, but insufficient to compensate for the schema gaps.

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 explicitly states it searches the governance audit trail with specific filters, and the tool is distinct from all sibling tools which focus on agents, policies, incidents, etc. No ambiguity.

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?

Provides an example question ('show denied tool calls in the last 24h') to guide usage. Does not explicitly state when not to use or compare to alternatives, but given sibling tools are unrelated, this is sufficient.

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

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

The description indicates a mutation ('Update') and mentions the required scope ('policies:write'). Annotations already confirm non-readonly and non-destructive. The description does not disclose additional behavioral traits beyond what annotations provide.

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 description is two sentences long, with the main action stated first. It is concise and includes a parenthetical note for clarity, with no wasted words.

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?

The description covers core functionality, scope requirements, and where to edit other fields. It lacks return value information, but since there is no output schema, that is not a major omission. For a mutation tool with 4 parameters, it is fairly complete.

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 coverage is 75%, and the description adds meaning by associating parameters with actions (e.g., 'rename it' for name, 'enable/disable' for enabled). However, the schema already provides good descriptions for most parameters, so the description's added value is marginal.

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 clearly states 'Update an existing policy' and lists specific fields (enable/disable, rename, change priority). It differentiates from sibling tools like axiorank_create_policy and axiorank_get_policy by focusing on update operations.

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 description implies when to use this tool: to update specific fields of a policy. It mentions that other fields are edited in the dashboard, providing an alternative. However, it does not explicitly state when not to use it.

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

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

Description adds behavioral details beyond annotations: mentions signature verification, supply-chain risk scoring, cross-tenant threat intel, and output format. However, annotations indicate readOnlyHint=false and openWorldHint=true, but the description does not clarify whether the tool has side effects or modifies state. This ambiguity prevents a higher score.

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 sentences, no wasted words. Purpose is front-loaded. Each sentence earns its place: first = action, second = parameters, third = behavior/output, fourth = usage/scope. Ideal structure for an AI agent to parse quickly.

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?

Despite no output schema, the description tells the agent what to expect: 'returns allow/review/deny' and 'resolved identity, capabilities and auth.' This is sufficient for a verification tool. However, it lacks details on error handling, what happens on failure, or the structure of the 'document' parameter. Completeness is good but not exhaustive.

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 coverage is 0%, but the description explains that 'url' (fetched by AxioRank) and 'document' (inline) are alternatives. This adds meaning for two of three parameters. However, the 'protocol' parameter (with extensive enum) is entirely unmentioned, leaving its purpose unclear. The description partially compensates but not fully.

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 clearly states the tool's purpose: 'Vet a remote agent or tool's identity card... BEFORE connecting to it.' It specifies card types, return values (allow/review/deny), and outputs (resolved identity, capabilities, auth). The verb 'vet' and explicit 'BEFORE connecting' make the action and scope precise. Distinguishes from siblings like axiorank_get_agent by focusing on pre-connection verification.

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?

Provides clear usage context: 'Use it as a connection preflight' and mentions required scope ('cards:verify'). Specifies two input modes (url or document). No explicit when-not-to-use or alternatives, but sibling list inherently differentiates. Slight deduction for missing exclusion guidance.

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