AxioRank: Zero-Trust for AI Agents

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

The description discloses that the AI proposes a detector and saves it disabled, emphasizing that an LLM never arms detection unattended. Annotations indicate non-read-only, open-world, non-idempotent, non-destructive; description adds behavioral nuance 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, front-loaded with core action, followed by key constraints. Every sentence adds value with no redundancy. Ideal conciseness for a low-parameter tool.

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

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

With only one parameter, no output schema, and low complexity, the description fully covers purpose, behavior, constraints, and usage prerequisites. No additional information is needed for correct invocation.

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 'description' has a schema description but the tool description adds value with examples ('e.g. flag AWS secret access keys') and context 'plain English'. Schema coverage is 100%, so baseline is 3, but extra context raises score.

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 creates a custom content detector from a plain English description, with specific verb 'author a detector' and resource 'detector'. It distinguishes from siblings as no other tool creates detectors; siblings involve 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 specifies scope (`policies:write`) and plan requirement (Team+), and limits use to 'outbound content categories only'. It does not explicitly state when not to use, but context is clear. Sibling tools are distinct, so no confusion.

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 details beyond annotations: it blocks briefly server-side, returns as soon as operator acts, and returns 'pending' if not yet decided. This aligns with and enhances the readOnlyHint, idempotentHint, and destructiveHint 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, each adding essential information: purpose, usage instruction, and behavioral details. No redundant words; front-loaded with the core action.

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 tool with one parameter, no output schema, and clear annotations, the description covers all necessary context: purpose, usage trigger, return behavior, and authentication requirements.

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

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

The only parameter approvalId is documented in the input schema with description referencing axiorank_score_tool_call. The tool description also mentions that the ID comes from that call, but adds no further semantic detail. With 100% schema coverage, baseline 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 tool polls the verdict of a held tool call, specifying the action (poll), resource (held tool call), and the source of the approvalId. This effectively distinguishes it from siblings as it references axiorank_score_tool_call which initiates the hold.

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 indicates when to use it (after axiorank_score_tool_call returns a hold decision) and what to do if pending (call again). It also mentions required scope and same agent key, providing clear context. 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?

Annotations indicate the tool is not read-only and not destructive, and the description adds value by detailing that the token is short-lived and no durable secret is emitted. This goes beyond what annotations alone provide, though it does not elaborate on other side effects (e.g., whether creation is immediate or if there are limits).

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 short sentences, each adding essential information: the core action and token behavior, long-term auth advice, and scope requirement. No redundant or extraneous text; the most important action is 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?

The description covers the main action and output (token), but there is no output schema to fall back on. It fails to explain what the tool returns besides the token (e.g., agent ID), and does not clarify the effect of optional parameters like labels or description. The tool's complexity (5 params) warrants a more complete 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?

With schema description coverage at 40% (only 2 of 5 parameters have descriptions in the schema), the description should compensate but does not add any parameter-level information. The description omits explanations for name, labels, and description, leaving these parameters without meaningful guidance.

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 a specific verb ('Create') and resource ('agent'), and adds key detail about returning a short-lived bootstrap token, making the tool's purpose clear. While it doesn't explicitly differentiate from the sibling axiorank_issue_token, the token context implies it's for initial creation, and the verb itself distinguishes from read/update/list 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?

The description states the required scope ('agents:write') and advises on post-creation steps for long-term auth, which provides some context. However, it does not explicitly tell when to use this tool versus alternatives like axiorank_issue_token, nor does it mention when not to use it. The usage guidance is implied rather than explicit.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that policies are created disabled, requires the 'policies:write' scope, and explains the action enum semantics (e.g., 'redact masks PII'). These are meaningful behavioral traits not present in the schema or 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 four sentences, each adding value: purpose, safety note, workflow, and parameter/scope details. No redundant or vague phrasing; all content is directly actionable.

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 tool has a complex optional `context` parameter, but the description focuses on the core create workflow, required scope, and action semantics. It does not describe the response return value or elaborate on optional conditions; however, the key steps (create→get→update) are covered. Given the complexity, slightly more detail could be added, but it's largely complete for a create 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?

With schema description coverage at 0%, the description must compensate. It explains `toolPattern` (glob over tool names) and `action` (allow/deny/require_approval/redact with redact semantics), but does not cover the other six parameters (name, context, priority, riskThreshold, signalCategory, enforcementMode). This partial coverage earns a mid-range score.

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' with a specific verb and resource, distinguishing it from sibling tools like axiorank_get_policy, axiorank_update_policy, and axiorank_list_policies. The workflow references make its unique role explicit.

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 instructs when to use this tool ('Create') versus siblings: 'Review it (axiorank_get_policy) then enable it with axiorank_update_policy.' It also explains the safety rationale for creating policies disabled, giving clear context on usage intent.

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 read-only and idempotent; description adds detail on returned fields (quarantine, labels, last-used, revocation) beyond annotations, increasing transparency.

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 verb 'Fetch', 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 simple tool with one parameter, good annotations, and no output schema, description is complete for an agent to select and invoke 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?

Single parameter agentId, schema description already covers UUID format and source. Description adds no additional parameter semantics; baseline 3 for 100% schema coverage.

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 tool fetches one agent's posture with specific fields (quarantine, labels, etc.) scoped to workspace. Distinct from sibling tools like list_agents (multiple) or quarantine_agent (action).

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?

Specifies scope ('your workspace') and required scope ('agents:read'), guiding when to use. Could be more explicit about not using for non-read operations, but 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 already indicate readOnlyHint, idempotentHint, and no destructiveness. The description adds value by specifying the exact resource checked (API + database) and the return format, which goes beyond what annotations provide. 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?

The description is extremely concise, consisting of two short sentences that convey all necessary information without any filler.

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

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

Given no parameters, no output schema, and annotations covering safety, the description is complete. It tells the agent exactly what the tool does and what to expect as output.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter information, and it correctly handles this by focusing on behavior.

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 is a liveness/readiness probe for the AxioRank control plane, specifying it checks API and database reachability and returns a status of 'ok' or 'degraded'. It distinguishes itself from sibling tools, none of which are health probes.

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 implicitly communicates when to use the tool (to check health), but it does not provide explicit guidance on when not to use it or alternatives. Given the simplicity of the tool, this is adequate, but not exemplary.

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 beyond that: returns null for non-kill-chain alerts and requires a specific scope. This provides useful context about edge cases and permissions, though it omits details like rate limits or error handling.

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: first concisely defines the purpose and output, second adds an edge case and required scope. No fluff, front-loaded with the core action. Every sentence earns its place.

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

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

With a single parameter, no output schema, and annotations covering safety, the description fairly explains the return (null for non-kill-chain) and mentions the output shape (pattern, severity, tool-call ids). It could be enhanced by describing the response structure more, but overall it's sufficient for a simple, read-only fetch.

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 the schema already describes the alertId parameter as a UUID from list_incidents. The description does not add any extra semantics or usage guidance 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (fetch kill-chain finding), the resource (alert), and the key details returned (multi-step attack pattern, severity, tool-call ids). It distinguishes from siblings like axiorank_list_incidents by focusing on evidence retrieval. The note about null evidence for non-kill-chain alerts adds precision.

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 requires an alert ID and the `logs:read` scope, which guides invocation. It implicitly suggests use when kill-chain details are needed, but does not provide explicit when-not-to-use or mention alternative tools like list_incidents. Given sibling names, 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 already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds the scope requirement (`policies:read`), which is valuable beyond annotations. No mention of error cases or return format, but given annotations cover safety, 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.

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

One concise sentence that starts with the core purpose ('Fetch one outbound policy by id'). No unnecessary words or repetition. All information 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 simple get-by-ID tool with a single parameter and good annotations, the description covers essential aspects (operation, scope, parameter source). Missing hints about return value or error handling, but these are not critical given the tool's 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?

Schema coverage is 100% with a description for the only parameter (policyId). The description does not add additional semantics beyond 'from axiorank_list_policies', which is already in the schema. 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?

Description clearly specifies the action ('Fetch'), resource ('one outbound policy by id'), and scope ('scoped to your workspace'). It distinguishes from siblings like axiorank_list_policies (lists all) and axiorank_create_policy (creates).

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 the use case (fetch single policy by id). While it doesn't explicitly mention alternatives like list_policies for listing all, the context and sibling names make the distinction clear. Lacks explicit '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.

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: protocols are grouped into six planes with coverage status and direction, which is beyond what annotations provide. 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 concise sentences that front-load the action and key information. The first sentence lists protocols and describes the output structure; the second provides usage guidance. 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?

For a zero-parameter read-only tool with no output schema, the description completely explains what the tool returns (protocols, planes, coverage status, direction) and provides usage context. Nothing is missing.

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

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

There are no parameters (input schema is empty), so schema description coverage is 100%. The baseline for 0 parameters is 4, and the description doesn't need to add parameter info.

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 'agent-interop protocols AxioRank can govern', and distinguishes itself from sibling tools by focusing on protocol coverage rather than specific 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?

The description explicitly says 'Use this to discover what AxioRank speaks before wiring up card verification or inbound bot management', providing clear context for when to use the tool. It does not explicitly mention 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the required scope and listing the data returned, which is not in 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 a single concise sentence that front-loads the purpose and lists outputs efficiently. Every part is informative without 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?

Given no parameters and no output schema, the description covers what the tool returns and a required scope. It could be slightly more complete by noting the response format, but overall adequate for a simple 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?

There are no parameters, so the description does not need to add parameter details. The baseline for 0 parameters is 4.

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 reports billing usage including plan tier, events used vs limit, and ML assessments. It provides a specific verb ('report') and resource ('usage for your workspace'), but does not explicitly differentiate from sibling tools like axiorank_get_health.

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 the required scope ('logs:read') and implies usage for viewing billing info, but does not explicitly state when to use it versus alternatives (e.g., other read-only tools) or 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?

Annotations indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds valuable details: token expires within the hour, cannot be replayed, and requires specific scope. This enriches the behavioral understanding 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?

Three concise sentences: first defines action and resource, second explains key properties (zero-trust, expiry, non-replay), third clarifies static key alternative and auth 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 3-parameter tool with no output schema, the description is nearly complete. It covers purpose, prerequisites, lifecycle constraints, and usage boundaries. A minor gap is the absence of return format details, but the purpose is well-understood.

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 input schema has 100% coverage with descriptions for all three parameters. The tool description reiterates the scoped nature and mentions default ttlSeconds (15 min), but does not add substantial new meaning beyond what the schema 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 specific verbs ('mint', 'issue') and identifies the resource as a short-lived access token for an existing agent. It clearly distinguishes this tool from sibling tools like 'create_agent' and 'revoke_agent' by specifying its unique role and even contrasts it with static key issuance via the 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?

The description explicitly states the required scope ('keys:write') and clarifies when not to use this tool (for durable static keys, use the dashboard). It provides clear context on the token's short-lived nature and non-replayability, guiding 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, destructiveHint=false, idempotentHint=true. The description adds meaningful context by specifying the required `agents:read` scope and the exact set of fields returned (id, name, labels, quarantine, last-used status), which is not evident from annotations alone.

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, front-loads the action and result, then provides usage guidance and scope. Every sentence is necessary and no fluff. It is perfectly concise and well-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?

Given no output schema, the description fully explains the return data (id, name, labels, quarantine, last-used status) and required scope. It is complete for a simple list tool with no parameters, covering all necessary information for an AI agent to use it correctly.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuously). According to scoring guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter information but does mention return fields, which is appropriate for completeness.

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 in the workspace with specific fields (id, name, labels, quarantine, last-used status). It explicitly states the purpose: to find an agent's ID before calling agent-specific tools, distinguishing it from sibling tools like axiorank_get_agent or axiorank_create_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?

The description explicitly says 'Use this to find an agent's id before calling agent-specific tools,' providing clear when-to-use guidance. It also implies when not to use (when ID is known) and mentions the required scope, giving comprehensive usage context.

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 readOnly, idempotent, non-destructive hints. Description adds ordering and filter capabilities, but does not significantly expand beyond the structured data. 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 with front-loaded action and filters, followed by a necessary 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 list tool with 4 optional params and no output schema, description provides core functionality and filters. Missing limit/pagination details, but ordering and filter options are covered. Sibling tools with similar patterns reduce need for exhaustive 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 coverage is 0%, so description must compensate. Description names three filter parameters (status, severity, kind) but does not explain enum values or mention the limit parameter. Partially compensates, but leaves gap for limit and lacks depth on filter options.

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 the tool lists security alerts/incidents, specifies ordering (newest first), and lists filterable dimensions (status, severity, kind). This distinguishes it from sibling tools like get_incident (single incident) and list_agents (different resource).

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?

Includes a prerequisite (logs:read scope) and implies use for listing incidents vs single retrieval, but does not explicitly state when to use this tool over alternatives or provide 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.

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read behavior. The description adds the scope requirement, which is helpful. However, there is no additional disclosure about behavior beyond listing, such as ordering or pagination. With annotations covering the safety profile, the description provides adequate but not rich context.

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, concise sentence that efficiently conveys purpose, included fields, and required scope. There is no fluff or redundant information, making it easy for an AI agent to quickly understand the tool's function.

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 optional parameter, no output schema) and comprehensive annotations covering safety, the description provides most necessary context. It explains what is listed and the required scope. The only gap is the lack of detail about the limit parameter, but overall completeness is high for a read-only 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?

The input schema has one parameter (limit) with 0% description coverage. The description does not explain the meaning, default, or constraints of the limit parameter. Since the schema alone provides defaults and bounds, the description adds no value for parameter semantics, falling short when coverage is low.

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 a specific verb 'List' and clearly identifies the resource 'ML/LLM threat assessments'. It further details the fields included (model verdict, threat class, confidence, recommendation) and scope (for tool calls and cards), effectively distinguishing it from sibling tools like axiorank_list_incidents or axiorank_list_policies.

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 'logs:read', which provides some guidance on prerequisites. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or specific contexts. The usage guidance is implied rather than explicit.

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 read-only and non-destructive behavior. The description adds the requirement for the `policies:read` scope and clarifies that both enabled and disabled policies are listed, 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?

The description is a single sentence that is concise and front-loaded. It efficiently communicates the tool's purpose, output fields, and authentication requirement. No superfluous 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?

For a list tool with no parameters and no output schema, the description fully explains the resource scope (workspace), what fields are returned, and the required scope. It is complete for this low-complexity 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?

With zero parameters and 100% schema coverage, the description does not need to add parameter details. It correctly has no parameter-related text, achieving the baseline for 0-param tools.

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 outbound governance policies in the workspace, including enabled or disabled ones, and specifies the fields returned (tool pattern, action, etc.). This distinguishes it from sibling tools like get_policy (single policy) and create_policy (creating policies).

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 the tool is for listing all policies in the workspace, but does not explicitly guide when to use it versus alternatives like get_policy for a single policy or search-related tools. No exclusions or when-not-to-use context is provided.

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 readOnly, idempotent, non-destructive. The description adds behavioral context: k-anonymity-gated aggregates, shared feed, and scope requirement. 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?

Two sentences, front-loaded with the main action, no redundant 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?

The description covers the tool's purpose, data content, and permissions. No output schema exists, but the description lists output types. Slightly less complete due to missing response structure details.

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 the description does not need to cover parameter details. Schema coverage is 100% by default. Baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists external identities with aggregate counts, specifies the data source (shared cross-tenant feed), and distinguishes it from private data. The verb 'list' and resource 'threat intel' are explicit.

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 `logs:read` scope and implies usage for cross-tenant threat intel. However, it does not explicitly advise when not to use it or compare it to sibling tools like `axiorank_list_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?

Discloses that quarantine denies all tool calls and that the action is reversible. Adds context beyond annotations (which mark destructive=true, idempotent=true) by specifying the gateway behavior and restore mechanism.

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 key metaphor and effect. Every word earns its place; no fluff.

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 simple params, no output schema, the description fully covers what the tool does, how to use it, and prerequisites. An agent can select and invoke correctly without ambiguity.

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 descriptions, but the description adds 'Set quarantine: false to restore' and connects agentId to the list_agents tool, providing practical guidance 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?

Clearly states the verb (quarantine/release) and resource (agent), with a concise metaphor 'Reversible kill switch'. Distinguishes from siblings like revoke_agent by emphasizing 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?

Explicitly mentions required scope ('agents:write'), implying the tool should be used when you need to temporarily block an agent's calls. Lacks explicit contrast with revoke_agent, but context is 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?

Beyond annotations (destructiveHint=true), the description adds critical details: immediate authentication stop, irreversibility, scope requirement (`agents:write`), and audit history preservation. 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?

The description is two tightly packed sentences that front-load key information (irreversibility, immediate effect) and include alternatives. 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?

For a single-parameter, no-output-schema tool, the description covers all essential aspects: operation, side effects, prerequisites, and alternatives. Nothing missing.

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

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

With 100% schema description coverage, the baseline is 3. The description does not add extra meaning beyond the schema's parameter description, which already provides the source (`from axiorank_list_agents`).

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 'Permanently revoke an agent' with specific consequences. It distinguishes from the sibling tool `axiorank_quarantine_agent` by contrasting irreversible vs reversible, 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 explicitly recommends using `axiorank_quarantine_agent` for reversible pauses, providing a clear when-to-use and when-not-to-use. It also frames the tool for 'incident response', giving context.

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 details the tool's functions: risk scoring (0–100), content inspection (secrets, PII, etc.), policy application, audit logging, and decision return. It goes beyond annotations by specifying the scope requirement ('gateway:write') and the approval workflow.

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 front-loaded with the primary purpose and lists features concisely. It is moderately sized and each sentence adds value, though slight further compression could be possible.

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 complexity (21 parameters, no output schema, nested objects), the description lacks essential context about how to populate parameters like 'tool', 'arguments', or 'context'. It is insufficient for correct invocation.

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 provides no explanation of any of the 21 input parameters. It fails to add meaning beyond the schema, which is a critical gap for such a complex tool.

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 a specific verb 'inspect' and clearly specifies the resource 'proposed agent tool call'. It distinguishes from sibling tools like axiorank_check_approval by stating its core risk-scoring and inspection function.

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 advises when to call it ('in your tool-use loop') and how to handle decisions ('refuse or wait on any non-allow decision'). It also references the sibling axiorank_check_approval for polling on hold, providing clear context for 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 declare readOnlyHint=true and destructiveHint=false. The description adds that results are newest first and payloads are secret-redacted, which are useful behavioral details 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 a single concisely structured sentence with clear sections, followed by an example and scope requirement. Every sentence adds value without 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?

Covers purpose, filters, ordering, redaction, and scope. Lacks mention of pagination or return format, but given the absence of an output schema, the description is fairly complete for a search tool with 8 parameters.

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%). The description explains the purpose of decision, source, agentId, tool (substring), minRisk, and time window parameters, adding meaning beyond the schema's type hints.

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 'search' and resource 'audit logs', with specific filters and ordering. It distinguishes itself from sibling tools that are CRUD operations on agents, policies, 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?

Provides a concrete usage example ('show denied tool calls in the last 24h') and notes the required scope. Does not explicitly mention when not to use it or alternatives, but context is 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?

Discloses required scope 'policies:write', which is beyond annotations. Annotations are neutral (no readOnly, no destructive), so description adds auth and field context. 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, front-loaded with action and scope. No redundant information; every part earns its place.

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?

Covers purpose, scope, and updateable fields. No output schema, so missing return value info is acceptable. Could mention if policy object is returned, but overall sufficient for typical use.

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 description adds little parameter-level detail beyond what schema already provides. The dashboard note clarifies scope but does not enhance individual parameter understanding significantly.

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?

Describes specific verb 'update' and resource 'policy', lists exactly what can be changed (enable/disable, rename, priority), and distinguishes from siblings like axiorank_create_policy and axiorank_get_policy. The note about dashboard scope clarifies boundaries.

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 (update existing policy) and implies when not (other fields via dashboard). Explicitly lists required scope, but could mention alternatives like create vs. update.

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 outlines the tool's behavior: it fetches the card, verifies signatures, scores supply-chain risk, folds in threat intel, and returns a verdict (allow/review/deny) along with resolved identity, capabilities, and auth. There is no contradiction with annotations (readOnlyHint=false indicates possible mutation, but the description does not mention side effects, which is acceptable for a verification tool). It adds 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?

The description is concise and front-loaded with the core purpose. It includes necessary details without excessive verbosity. However, it could be slightly more structured (e.g., using 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 absence of output schema and low schema coverage, the description provides a good overview of inputs, process, and outputs. It explains the verdict types and the resolved identity, capabilities, and auth. Missing are error conditions or what happens with invalid cards, but overall it is sufficient 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?

The description adds meaningful context to the parameters: it explains that 'url' is for AxioRank to fetch the card and 'document' is for inline input. It also lists supported protocols, although it does not detail each one. With 0% schema coverage, this description compensates well.

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: to verify an identity card (A2A Agent Card, MCP server card, etc.) before connecting. It specifies the action ('vet'), the resource ('identity card'), and distinguishes it from sibling tools as a preflight verification step.

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 says 'BEFORE connecting to it' and instructs the agent to supply either a URL or an inline document. It also mentions the required scope. However, it does not explicitly state when not to use this tool or provide alternative tools for similar tasks, which would be helpful.

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