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

Annotations already mark the operation read-only and non-destructive, and the description adds meaningful behavior: what the lookup returns, that querying is case-insensitive, and that omitting parameters lists every concept. It does not specify edge cases such as behavior when both parameters are provided or when no match is found, but it exceeds the annotation baseline.

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 action and then explains returned content and parameter modes. It is slightly verbose due to the enumerated vocabulary examples, but each sentence carries functional guidance and no 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?

With no output schema, the description compensates by naming the categories of returned data and the two lookup modes. It is complete enough to select and invoke correctly; the only minor gaps are exact response shape and pagination/limit behavior on the list-all path.

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%, and the description adds value beyond the schema by providing example ids, clarifying that 'query' is a substring search across id/term/definition, and documenting the omit-both default. This goes beyond the baseline without fully specifying interplay between the two parameters.

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 opens with a specific verb and resource: 'Look up a canonical AtlaSent concept from the Knowledge Atlas.' It further distinguishes the tool by listing the returned artifact types and the exact vocabulary examples, so an agent can separate this lookup from the many sibling policy/audit/permit 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?

It gives explicit invocation modes: use 'id' for exact matches, 'query' for a case-insensitive substring search, and omit both to list all concepts. It stops short of explicitly naming sibling alternatives or when-not-to-use conditions, so it is clear but not fully exclusionary.

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 valuable behavior beyond that: the check does not consume the permit, returns a specific status object, and is purely a status read rather than an authorization decision.

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 focused sentences deliver the core operation, return contract, and usage guidance without unnecessary detail. The key non-consuming behavior 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?

For a single-parameter read-only tool with no output schema, the description fully covers what the tool returns, what status values exist, and when to call it. The agent has enough information to invoke 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 schema fully documents permit_id with 100% coverage, including its type and source from atlasent_list_permits. The description does not add parameter-specific detail, so 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 says exactly what the tool does: check whether a permit is still usable without consuming it. It also distinguishes itself from atlasent_verify_permit by clarifying that this is a status read, not authorization.

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 when to use the tool: before a deferred action to avoid acting on a revoked permit. It also gives an important exclusion, noting this is not authorization and must be executed only after atlasent_verify_permit.

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 this is a non-read, non-destructive write operation, so the bar for extra disclosure is lower. The description adds meaningful context: it explains the request ID source, the resolution path, and the semantic boundary that approval does not itself authorize or prove execution. It does not detail side effects like whether duplicate requests are possible, but the core behavioral contract is clear.

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 with no filler. The core action is front-loaded, the source of the request ID is given, the resolution sibling is named, and the semantic boundary is stated. 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?

For a create tool with no output schema, the description covers the trigger condition, the required input relationship, and the follow-up action. It does not describe the response shape or whether the request ID is returned synchronously, but the description's explicit link to the evaluate response and resolver tool gives an agent enough to call 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?

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds the crucial relationship between the request ID and the evaluate response, but it does not add per-parameter meaning beyond the schema. 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 states a specific verb and resource ('Create an approval request for a held action') and immediately distinguishes it from the sibling resolver tool by naming atlasent_resolve_approval_request. It also clarifies the relationship to Authorization, which prevents confusion with the evaluate/permit 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 explicitly says when to use this tool: when a decision is 'hold' and a request ID is returned in the evaluate response. It also names the alternative for submitting resolution and clarifies that approval is an input to Authorization, not an authorization itself. This is strong routing 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 (readOnlyHint=false, destructiveHint=false) indicate a non-destructive mutation. The description adds behavioral details: returns SHA-256 for tamper verification and default 90-day window. However, it omits other important behaviors like synchronous/asynchronous nature, idempotency, or side effects. Given annotations, the extra context is moderate.

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 with no wasted words. The first sentence states the purpose and key output, the second explains the default window and parameter usage. It is front-loaded with the most critical 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?

Given 4 parameters, no output schema, and annotations present, the description covers the core use case, constraints, and behavior. It mentions the SHA-256 return. However, it does not describe the full response structure or error cases. For a creation tool, this is largely sufficient 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 100%, so baseline is 3. The description adds value by explaining the default window (past 90 days) and how to narrow it using date_from/date_to, which is not in the schema. It also mentions the enterprise plan requirement implicitly linking to org_id. This goes beyond the schema descriptions.

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: generating a compliance evidence bundle for specific audit regimes. It uses a specific verb ('Generate') and resource ('compliance evidence bundle'), and distinguishes itself from siblings like 'get_evidence_export' (retrieve) and 'list_evidence_exports' (list).

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 mentions a prerequisite ('Enterprise plan required') and provides guidance on default window and narrowing with parameters. However, it does not explicitly state when not to use or compare to alternatives, but the context is clear enough for selection vs sibling tools.

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 only mark the tool as non-read-only and non-destructive; the description adds real behavior: a newly created policy is not immediately active — it is in draft and requires a later update_policy call to become published. This materially changes how an agent should reason about the effects of calling create.

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 short sentences with no filler. The core action and the lifecycle caveat are both front-loaded, and the second sentence earns its place by naming the follow-up 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?

Despite the helpful lifecycle note, this is a 12-parameter creation tool with nested, loosely specified objects (rules, actions, applies_to) and no output schema. The description doesn't explain response behavior, duplicate-handling, or the structure expected inside the nested objects, so an agent is left to infer those from sparse schema entries.

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?

All 12 parameters already have individual descriptions in the input schema, so the dimension baseline is 3. The tool description adds no parameter-level meaning beyond that; the schema carries the burden successfully.

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

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

States a specific verb ('Create') and resource ('constraint bundle') and immediately orients the agent to the policy lifecycle by noting the new bundle starts in 'draft' status. It also distinguishes this creation tool from the sibling update_policy, since publishing is explicitly assigned to that tool.

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 gives the main routing signal: use this tool to create a new bundle, and call update_policy to publish it. It doesn't enumerate all siblings (list/get/delete), but for a create operation the create-vs-update distinction is the critical one and is 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 non-read-only and non-destructive. The description adds that the user becomes available for policy evaluation, but no additional behavioral traits like idempotency or error handling are disclosed. Minimal added 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?

The description is two sentences, front-loaded with the core purpose, and no wasteful content. Every word 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?

As a creation tool with 7 parameters and no output schema, the description does not explain what the tool returns. However, it covers the essential purpose and implications (availability for policy evaluation). Minor gap in return value context.

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

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

Schema coverage is 100%, with each parameter having a description. The description does not add extra meaning beyond what the schema already provides, so 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 it provisions a new SCIM user and adds to the directory for policy evaluation. The verb 'Provision' and resource 'SCIM user' are specific, and it distinguishes from sibling tools like delete, patch, and get.

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 does not specify when to use this tool versus alternatives, nor does it mention prerequisites like an existing org. Usage is implied but not explicitly guided.

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 it's a mutable (readOnlyHint=false) but non-destructive operation. The description merely says 'register', which aligns but adds no extra behavioral details such as idempotency, side effects, or requirements.

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 sentence. No wasted words, and it conveys the core purpose directly.

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 creation tool with 5 parameters and no output schema, the description lacks critical context about return values, activation behavior, or verification steps. It is minimally adequate but not 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?

All 5 parameters have full schema descriptions (100% coverage). The tool description adds no additional meaning beyond what is already in the schema, so baseline score 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 the action (register), the resource (webhook URL), and the purpose (to receive evaluation events). It distinguishes well from sibling tools like delete_webhook or list_audit_events.

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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The description is too terse to help an agent decide contextually.

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 value beyond the annotations by stating 'Permanently delete' and 'Prefer archiving', which warns of irreversibility and suggests caution. Annotations already have destructiveHint=true, so the description reinforces this. No behavioral contradictions. Some missing details (e.g., what happens if dependencies exist) but acceptable for the destructiveHint flag.

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 no wasted words. The first sentence immediately states the action, and the second provides a usage preference. 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?

Given low complexity (2 required parameters, no output schema) and annotations covering destructive behavior, the description is nearly complete. It could mention auth requirements or the irreversible nature more explicitly, but the 'permanently delete' phrase covers that. Lacks details on success/error responses, but no output schema exists to justify that.

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 both org_id and policy_id already described in the input schema. The description adds no additional parameter details. Baseline score of 3 is appropriate since the schema itself is sufficient.

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 'Permanently delete a constraint bundle' uses a specific verb+resource, clearly stating the action and object. It distinguishes from sibling deletion tools like atlasent_delete_scim_user and atlasent_delete_webhook by specifying 'constraint bundle'. The additional note 'Prefer archiving over deleting' adds further clarity on the tool's purpose.

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 archiving over deleting, providing implicit guidance on when not to use this tool. However, it does not directly mention specific alternatives (e.g., atlasent_update_policy) or detailed context for when deletion is appropriate beyond permanence. This is good but could be more 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 set destructiveHint=true, so the description's 'irreversible' adds minimal extra. No additional behavioral details (e.g., permissions required) are provided.

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 are concise and front-loaded with the core action. No extraneous 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 simple two-parameter tool with no output schema and annotations covering destructiveness, the description is complete enough. It includes irreversibility warning and usage alternative.

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 clear descriptions for both parameters. The description adds no extra 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 title and description clearly state the action 'Delete SCIM User' and resource 'AtlaSent directory'. It distinguishes from sibling tools like atlasent_patch_scim_user which disables instead.

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 advises preferring disable over delete, mentioning the alternative 'patch active=false'. This helps the agent choose the correct action.

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 set destructiveHint to true, so the agent knows this is destructive. The description adds 'Remove' which aligns. No additional behavioral traits (e.g., cascading effects, reversibility) are disclosed. With annotations covering the main safety concern, a 3 is reasonable.

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?

Single sentence 'Remove a registered webhook.' is highly concise and front-loaded. 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 simple deletion by ID, the description is adequate but minimal. No output schema exists, and no context about effects or confirmation is provided. Given the tool's simplicity, it meets the minimum viable level.

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 fully documented in the schema. The description does not add any extra meaning beyond the schema's property descriptions. Baseline 3 applies.

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

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

The description states 'Remove a registered webhook.' which clearly identifies the action (remove) and resource (webhook). However, it does not distinguish from sibling tools like 'atlasent_create_webhook' or 'atlasent_delete_policy', so a 4 is appropriate.

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?

No guidance on when to use this tool versus alternatives. With siblings like 'atlasent_create_webhook' and other delete tools, the description does not specify when deletion is appropriate or mention prerequisites.

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 discloses the decision values and permitToken, which is important because there is no output schema. However, beyond the basic annotations it does not reveal side effects (e.g., whether an audit record is created), expiration or verification expectations, or behavior for hold/escalate beyond the enum-like return.

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 tight sentences lead with the core action and return type, then give the mode condition. No wasted words and the key information 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?

For a no-output-schema tool with six parameters and many siblings, the description covers the essential outcome and the primary selection condition. It does not explain how permitToken should be used afterward or expand on hold/escalate semantics, but the rich schema descriptions compensate for most 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 description coverage is 100%, and the prose description adds no parameter-level meaning beyond what the schema already provides. The schema itself supplies useful semantics such as the context object and binding behavior of target_id and execution_payload_hash, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Evaluate an action against your published AtlaSent policies') and names the output (allow/deny/hold/escalate with a permitToken). It distinguishes remote mode from any local evaluation path, though it does not explicitly name sibling tools like atlasent_evaluate_many or evaluate.

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

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

It gives an explicit condition ('Use this when ATLASENT_MODE=remote') and the intended purpose (gate an action against the hosted policy engine). It does not state when to prefer alternatives such as atlasent_evaluate_many or atlasent_verify_permit, so exclusions are missing.

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 (readOnlyHint=false, destructiveHint=false), description adds that results are returned in input order, batch_id provides idempotency, and closed-by-default errors are tagged with feature_not_enabled. This gives useful behavioral 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?

Three sentences, no wasted words. Purpose is front-loaded, then returns order, idempotency, and error behavior are efficiently stated.

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 exists, so description should ideally explain return format. It says 'returns decisions in input order' but lacks details on decision structure, batch status, or potential errors. Adequate for basic understanding but incomplete for complex 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 100%, but description adds value by clarifying the items array returns decisions in input order and batch_id provides idempotency, which is not evident from the schema alone.

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 it evaluates up to 100 actions against AtlaSent policies, returning decisions in input order. The verb 'evaluate' and resource 'many actions' are specific, and it implicitly differentiates from siblings like atlasent_evaluate (singular) and atlasent_evaluate_stream (streaming).

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

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

Implies batch usage by stating 'up to 100 actions' and 'single request', but does not explicitly say when to use this vs. atlasent_evaluate or atlasent_evaluate_stream. No when-not or alternatives given, leaving the agent to infer.

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 valuable behavioral context: per-item RPC failures return {error} and stream continues, and closed-by-default 404 surfaces as feature_not_enabled error. Annotations are minimal, so description carries the burden well.

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 focused sentences: purpose, error handling, special case. No wasted 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?

Covers key aspects (max items, error handling, special 404 error) and references sibling's return shape. Missing explicit return schema is offset by 'same shape' reference.

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 clear descriptions. The description adds no further parameter details beyond 'same shape as atlasent_evaluate_many', which is implicit for the items array.

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 evaluates up to 100 actions via streaming, distinguishing itself from synchronous evaluate variants with 'streaming endpoint' and 'same shape as atlasent_evaluate_many'.

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?

No explicit guidance on when to use this streaming version versus atlasent_evaluate or atlasent_evaluate_many. The 100-item cap is mentioned but not as a decision criterion.

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, and the description compounds this by explicitly stating it 'does not change /v1-evaluate, /v1-verify-permit, or any deny/hold/allow semantics.' It also discloses output structure: matched mechanisms are reported as path entries, excluded/ambiguous relationships as unresolved findings. This is rich behavioral 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 sentences deliver the core purpose, read-only guarantee, relationship to sibling paths, and output behavior with no filler. The most important information is front-loaded in the first sentence.

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 read-only explanation tool with no output schema, the description covers the key aspects an agent needs: what question it answers, that it is non-mutating, and what kind of findings it returns. It does not describe exact response fields or error behavior, but the absence is minor given the tool's explanatory nature and the strong sibling differentiation.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters and even includes wire-format guidance for requested_scope. The tool description itself adds no parameter-level meaning, which matches the baseline of 3 for fully covered schemas.

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 names a specific verb ('explain'), a specific resource ('authority for a scope'), and the exact question being answered. It also enumerates authority mechanisms (direct_grant, delegation, role_capability), making it clearly distinguishable from sibling evaluation/verification 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 states that the tool is strictly read-only and that it 'explains the same facts those paths already read,' referencing /v1-evaluate and /v1-verify-permit. This gives clear context about its relationship to evaluation/verification tools, though it does not explicitly say 'use this instead of X when...'.

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 safety profile is known. The description adds useful behavioral context: which fields are returned, what include_trace adds, and the required audit:read permission.

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 with no filler. The core purpose is front-loaded, the optional flag behavior is stated briefly, and the auth requirement is included without wasting 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 read-only get-by-id tool with only two simple parameters, the description covers what is needed to call it correctly: the resource, the lookup key, the optional expansion behavior, and the permission requirement. No output schema exists, but the returned fields are enumerated sufficiently.

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 documents evaluation_id as a UUID and include_trace's effect. The description mostly restates this information without adding new parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Fetch one authorization decision (execution evaluation) by id'. It also lists the exact fields returned, making the tool's purpose unambiguous and easily distinguishable from sibling list/evaluate/check 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 makes it clear this is the get-by-id tool for a single decision and explains the optional include_trace behavior. It does not explicitly name alternatives or exclusions, but the usage context is clear enough for an agent to choose it appropriately.

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. Description adds behavioral details: response includes status, SHA-256 hash, and download URL when complete. 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?

Single sentence, front-loaded with key action, no unnecessary words. Perfectly concise.

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 adequately specifies return fields (status, hash, URL) and condition ('when complete'). Lacks error scenarios but sufficient for a simple retrieval 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 parameter descriptions. Description only adds marginal context ('by ID') but does not significantly enhance understanding beyond schema. 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?

Description explicitly states 'Retrieve a specific compliance evidence bundle by ID' with verb+resource clarity. Differentiates from sibling tools like 'list_evidence_exports' and 'create_evidence_export'.

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?

Usage is clear: use when you have an export ID. Does not explicitly state when not to use or provide alternative comparisons, but context signals and tool name make it obvious.

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, so the safety profile is covered. The description adds genuine value beyond that: it discloses the exact return contents and, critically, the negative guarantee that the permit token is never returned — a non-obvious behavioral limitation an agent would not otherwise know. This is strong added context for a tool with no output schema.

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 filler. The primary action and return contents are front-loaded, and the critical token caveat is placed in a short second sentence. Every clause 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?

For a single-parameter, read-only tool with full schema coverage and a safety profile in annotations, the description covers the essential ground: what is retrieved and a key limitation. The return field list compensates for the missing output schema. Minor gaps remain — error behavior for a nonexistent permit_id and explicit sibling routing — but nothing blocks 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 100%, and the permit_id parameter is fully documented in the schema as a UUID returned by atlasent_list_permits. The description itself adds no parameter-level meaning beyond what the schema already provides, so the baseline 3 applies.

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

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

Uses a specific verb ('Fetch') with a precise resource ('one permit's record') and enumerates the exact fields returned (status, actor, action, environment, issue/expiry/consume times, decision). The 'one permit's record' phrasing cleanly separates it from atlasent_list_permits, and the final clause distinguishes it from token-returning 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?

Usage context is implied: 'one permit's record' signals this is for single-record retrieval rather than listing, and 'Never returns the permit token itself' hints that token-seeking callers should look elsewhere. However, no alternative tool is named, and it doesn't explicitly state when to use this over atlasent_check_permit, atlasent_verify_permit, or atlasent_get_decision, leaving routing partially to inference.

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. Description adds no additional behavioral context (e.g., authentication, rate limits, idempotency). Adequate but not additive.

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?

Single sentence of 9 words, no unnecessary information. Extremely concise 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 retrieval tool with two well-documented parameters and annotations present, the description is sufficient. It could mention the return value, but not required as there is no output schema. Nearly 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 100% with both parameters having clear descriptions. The tool description adds no further parameter semantics. 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 'retrieve', the resource 'constraint bundle / policy', and the method 'by ID'. It distinguishes from sibling tools like atlasent_list_policies, which lists multiple 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?

No explicit guidance on when to use this tool versus alternatives. Usage is implied (retrieve a single policy by ID), but no exclusion criteria or context provided. Siblings like atlasent_list_policies and atlasent_create_policy exist.

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, so the description's 'retrieve' aligns. No additional behavioral traits (e.g., authentication, rate limits) are disclosed 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?

Single sentence, zero waste, front-loaded with the key action and resource. 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?

For a simple read operation with only two parameters and clear annotations, the description is complete and sufficient. No missing information.

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 for both parameters. The description does not add any meaning beyond the schema, so baseline score of 3 applies.

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

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

The description uses a specific verb ('retrieve') and resource ('provisioned SCIM user') with a clear method ('by ID'), clearly distinguishing it from sibling tools like list_scim_users or create_scim_user.

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?

No guidance on when to use this tool versus alternatives such as list_scim_users. The description only states the retrieval method (by ID) but does not explain prerequisites or 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 already provide readOnlyHint: true and destructiveHint: false. The description adds behavioral context: the enterprise plan requirement and that the credential field is never returned, which is 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 two sentences, no redundant words. The purpose is front-loaded in the first sentence, making it immediately clear.

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 read operation with one parameter and no output schema, the description covers the core purpose and two important caveats. It could mention that the response is the config object, but this is 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?

Schema description coverage is 100% for org_id, with a brief description 'Organization ID.' The description adds no further semantic detail, so 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 'Retrieve the SIEM export configuration for an organization,' using a specific verb and resource. It distinguishes from siblings like atlasent_upsert_siem_config and atlasent_test_siem_delivery, which handle create/update and testing respectively.

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 'Enterprise plan required,' providing a clear prerequisite. It does not explicitly state when to use vs. alternatives, but the sibling list and name imply this is for reading. The credential warning also guides expectations.

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 readOnlyHint and destructiveHint annotations, the description adds crucial behavioral details: strict read-only behavior, three-way classification semantics, the meaning of 'unresolved', the need to check summary.audited_scope before interpreting empty findings, and server refusal on incomplete audits. This substantially exceeds what annotations alone convey and prevents dangerous misinterpretation.

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 long but every sentence earns its place by preventing a serious misreading: no pass/fail, classification meanings, empty-findings caveat, and partial-report refusal. It is front-loaded with the core purpose and read-only guarantee, then layers essential semantic warnings. No filler or 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?

There is no output schema, so the description carries the full burden of explaining result interpretation, and it does so thoroughly: classifications, audited_scope caveat, empty-report behavior, and error semantics. For a one-optional-parameter read-only tool with this complexity, nothing an agent needs to call and interpret it correctly 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?

The input schema has 100% coverage and already thoroughly documents decision_window_days, including its optionality, range, omission behavior, and echo in summary.audited_scope. The main description adds no parameter-level information beyond what the schema provides, so the baseline 3 for high schema coverage 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 opens with a specific verb and resource: 'Audit the organization's authority graph for internal inconsistency and return the report verbatim.' It clearly distinguishes the tool from a health check or verdict-producing tool, which separates it from siblings like atlasent_vqp_drift_events or evaluate. The scope and output mode are unmistakable.

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 gives clear context for when this tool is appropriate: auditing for internal inconsistency, read-only, no pass/fail verdict. It explains what the tool is not ('THIS IS NOT A PASS/FAIL HEALTH CHECK') but does not explicitly name alternative tools or conditions for choosing them over this audit. This is clear context with a notable exclusion, but not full alternative routing.

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. The description adds 'recent' but this is vague and potentially misleading since the to/from parameters allow arbitrary time windows. No mention of ordering, pagination behavior (beyond limit), or what happens when the window is empty.

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 no redundancy. However, it could be front-loaded with key differentiators (e.g., 'audit log' specificity) and still remain concise.

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 exists, so the description should compensate by explaining return structure or field examples. It does not. Also lacks information on event ordering, time zone handling, or filtering effects. For a tool with 5 parameters and many siblings, this is insufficient.

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 parameter descriptions exist and are clear (ISO-8601, limit range, required org_id). The description adds no additional parameter context; 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 ('Retrieve') and the resource ('evaluation events from the audit log'). This is distinct from sibling list tools like list_evidence_exports or list_policies, making the 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?

No guidance on when to use this tool versus alternatives (e.g., list_evidence_exports for different event types). The description does not mention context, prerequisites, or exclusions.

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 and non-destructive. The description adds that each record includes status and SHA-256 hash, and the enterprise plan requirement, but does not disclose additional behavioral traits such as pagination 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?

The description consists of two concise sentences with the purpose front-loaded. No redundant information is present.

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 purpose, plan requirement, and return record fields. Missing details like pagination or default filter are minor given the tool's simplicity and existing annotations.

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 for both parameters (org_id, regime). The description does not add new meaning beyond the schema, maintaining the baseline 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 uses the specific verb 'list' and identifies the resource as 'compliance evidence bundles' for an organization. It clearly differentiates from sibling tools like 'atlasent_create_evidence_export' and 'atlasent_get_evidence_export'.

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 'Enterprise plan required' as a prerequisite but does not explicitly guide when to use this tool versus alternatives like 'get_evidence_export'. Usage is implied from the verb but lacks explicit when-not or alternative references.

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. The description adds no new behavioral traits beyond stating the listing purpose, which is consistent.

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?

Single sentence, no wasted words. Efficiently communicates the tool's core 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 presence of pagination parameters (cursor, limit) and filters, the description is minimal but adequate. It does not mention pagination behavior or output format, but these are not strictly required given the schema richness.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions.

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 issued permit tokens, with a specific use case (audit and monitoring). This distinguishes it from sibling tools that create, revoke, or verify permits.

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?

Description implies usage for audit/monitoring but does not explicitly state when not to use or provide alternatives among sibling tools like atlasent_revoke_permit or atlasent_verify_permit.

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 it lists 'all' policies for the organization, but does not elaborate on pagination, ordering, or other behavioral traits. Minimal additional 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 a single, concise sentence that directly states the action and scope. No wasted words; front-loaded with key 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 simple list tool with two parameters and no output schema, the description is nearly complete. It could optionally mention pagination or ordering, but these are not critical for basic usage.

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 clear descriptions for both parameters (org_id and status). The description does not add extra meaning beyond what the schema already provides, so 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 explicitly states the verb 'List' and resource 'constraint bundles / policies', scoped to 'this organization'. It clearly distinguishes from siblings like 'atlasent_get_policy' (singular) and 'atlasent_list_evidence_exports'.

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?

No explicit when-to-use or when-not-to-use guidance is provided. The usage is implied by the tool's name and context, but no alternatives or exclusion criteria are mentioned.

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=true and destructiveHint=false, so the description adds little behavioral context. It mentions SCIM 2.0 protocol and organization scope, which is useful but minimal. 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 a single sentence, concise and front-loaded with the key action. However, it could be slightly more informative without losing conciseness.

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 could mention return values (e.g., list of group objects) or pagination behavior. The schema covers parameters, but the description is minimal for a list 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?

Input schema covers 100% of parameters with descriptions. The description does not add further semantic detail beyond what the schema provides, so 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 lists provisioned groups via SCIM 2.0 for an organization. It specifies the protocol (SCIM 2.0) and scope (organization), but does not explicitly differentiate from sibling tools like atlasent_list_scim_users beyond the resource name.

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?

No explicit guidance on when to use this tool versus alternatives. The name and resource type imply distinction, but the description lacks direct context for selection, e.g., when to use list_scim_groups vs list_scim_users.

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, and the description adds valuable behavioral context: compliance with SCIM 2.0, support for filter expressions and pagination (startIndex/count). No 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?

Two concise sentences that front-load the core purpose and add essential details. 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?

The description covers the tool's purpose, standard, and parameters well. However, it does not mention the return format (e.g., list of user objects in SCIM format). Given no output schema, describing the response structure would improve completeness.

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?

All 4 parameters are well-described in the schema (100% coverage). The description adds value by providing examples of SCIM filter syntax and mentioning pagination behavior, enhancing understanding 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 lists SCIM users for an organization, referencing the SCIM 2.0 standard and RFC 7643. It distinguishes from sibling tools like get_scim_user (single user), create/delete/patch, and list_scim_groups by specifying it's for listing provisioned users with filtering and pagination.

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 this tool (listing provisioned users) and hints at syntax (filters, pagination). However, it does not explicitly mention when not to use it or alternatives like get_scim_user for single user retrieval.

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, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it discloses that query ranking is performed offline, that it returns a retrieval block with confidence levels (confident/ambiguous/none), and that the tool never invents action types. This goes beyond the annotations and helps the agent understand edge cases. It doesn't fully detail the return format but provides sufficient 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 dense but well-organized, front-loading the purpose and then systematically covering parameters, confidence handling, and the full-canon listing. Every sentence contributes new information without redundancy. While it is long, the length is justified given the tool's complexity and the absence of an output schema. It could be slightly more concise, but it earns a 4.

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 lookup tool with no output schema and two optional parameters, the description is remarkably complete. It enumerates all the returned fields (canon_id, gate flags, authorization pattern, risk posture, AI risk classification, regulatory mappings, evidence requirements, knowledge-graph relationships), explains the retrieval confidence mechanism, and covers the edge case of 'none' results. An agent has everything needed to decide when to call and what to expect.

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?

Although schema coverage is 100% (both parameters have descriptions), the tool description adds substantial meaning beyond the schema. It explains the difference between slug (exact match) and query (plain-language, ranked deterministically), provides concrete examples for each, and describes the behavior of query ranking (offline, over slug, display name, family, etc.). This significantly enhances the agent's ability to use the parameters correctly.

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 the tool looks up canonical action specifications from the Authorization Intelligence Library, and enumerates the specific fields returned (canon_id, gate flags, authorization pattern, risk posture, etc.). This is a specific verb-resource combination that clearly distinguishes it from sibling tools like atlasent_list_policies (which manage policies) or atlasent_explain_authority (which explains authority). The purpose is unambiguous and detailed.

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 gives clear usage guidance on how to invoke the tool: use 'slug' for exact match, 'query' for plain-language description, or omit both to list the full Canon. It also instructs the agent to act only on 'confident' retrieval confidence and explains the meaning of 'none' results. However, it does not explicitly name alternative tools or state when NOT to use this tool versus siblings, though the purpose clarity makes that largely implicit.

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 readOnlyHint=false and destructiveHint=false, indicating a non-destructive mutation. The description adds that it uses SCIM PatchOp but does not disclose additional behavioral traits such as idempotency, 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?

The description is two concise sentences. It front-loads the core purpose and briefly explains operation format with no extraneous content.

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 core functionality but lacks context about return values, permissions, or error cases. For a mutation tool with no output schema, more details would improve completeness.

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

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

Schema description coverage is 100%, so the schema fully documents parameters. The description summarizes the operation structure but does not add new semantics beyond what is in the schema. Baseline 3 applies.

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

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

The description clearly states the tool updates a provisioned user using SCIM PatchOp operations, specifying the verb 'update', resource 'user', and protocol. It is distinct from sibling tools like create_scim_user and delete_scim_user.

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 use for partial updates via PatchOp but provides no explicit guidance on when to use this tool vs alternatives (e.g., create, delete). It lacks context like prerequisites or exclusions.

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 non-read-only and non-destructive. Description adds no behavioral context beyond 'issue a permit token' – no mention of permissions, side effects, or limits. With annotations present, description carries minimal extra value.

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 purpose. No wasted words. Efficient and clear.

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 6 parameters (4 required), nested objects, no output schema, and sibling tools like verify/revoke permit, the description is adequate but minimal. It explains the high-level purpose but lacks workflow context or return value expectations.

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 for all 6 parameters. Description does not elaborate on parameters beyond the schema, so baseline score of 3 applies. No additional semantic value from description.

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 'issue a permit token for an action' with specific verb and resource. It distinguishes from evaluate siblings by mentioning 'pre-authorized operations where a full evaluate call is not practical.'

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 for pre-authorized operations instead of evaluate, providing clear context. Lacks explicit when-not-to-use or alternatives beyond evaluate, but the guidance is sufficient for typical scenarios.

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, etc. The description adds behavioral details beyond annotations: body limit 1MB, depth limit 8, single operation enforced server-side, and error behavior for 404. 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, with three sentences that are front-loaded: purpose, technical limits, and error behavior. Every sentence adds essential information 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?

For a read-only GraphQL query tool with no output schema, the description covers purpose, schema fields, limits, and error behavior. Missing details like authentication or rate limiting are partially addressed by annotations (openWorldHint). Adequately complete for the tool's 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 coverage is 100%, so the input schema already documents the query and variables parameters. The description provides context about the endpoint and available schema fields (recentEvaluations, activeBundle) but does not add parameter-specific 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 clearly states the tool runs a read-only GraphQL query against the AtlaSent V2 endpoint, specifying the schema and distinguishing it from sibling tools that handle mutations or other data retrieval methods. The title reinforces 'read-only'.

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 usage for read-only GraphQL queries and warns about the 'closed-by-default' feature availability error, but does not explicitly state when to avoid this tool or mention specific alternatives among the extensive sibling list.

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 show readOnlyHint=false and destructiveHint=false, so the write-but-not-destructive nature is established. The description adds useful workflow context: it records the observed outcome and is explicitly not a pre-execution verification step. It does not discuss idempotency or failure behavior, but that is less critical given the clear workflow framing.

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 no filler. The action and its relationship to the prior evaluate call are front-loaded, and the exclusion is stated succinctly.

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 five-parameter tool with no output schema, the description explains the purpose, timing, required prior step, and key exclusion. Minor omissions include naming the exact alternative verification tool and stating return/side-effect behavior, but the schema and annotations carry the remaining load.

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 documents evaluation_id provenance, the outcome enum, and optional fields. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb ('Record') and a clear resource ('the outcome of an execution that was permitted by a prior evaluate call'). It also distinguishes itself from related workflows by noting it does not replace pre-execution Permit 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?

Explicitly establishes when to use the tool: after an execution permitted by a prior evaluate call, to close the evidence loop. It also gives an exclusion ('does not replace pre-execution Permit Verification'), though it does not name the exact sibling tool to use instead.

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 readOnlyHint=false and destructiveHint=false, but the description goes further by disclosing that 'Approval records a verified input; the protected action must still satisfy the current authorization/reevaluation path and Permit Verification before execution.' This is a critical behavioral nuance that clarifies that approving is not a final authorization—it only records input. This adds significant context beyond the annotations and helps the agent understand the tool's side effects.

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 and front-loads the core action in the first sentence. The second sentence adds essential behavioral context without fluff. There is zero redundancy, and every word earns its place. It is 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?

For a simple approve/deny tool, the description covers the main action and the important caveat about the protected action still requiring authorization and Permit Verification. It does not describe return values or error scenarios, but since there is no output schema and the tool's purpose is straightforward, this is not a major gap. The description is complete enough for an agent to invoke it correctly in most cases.

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

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

Schema description coverage is 100%, so all five parameters are already documented with descriptions. The description does not add any parameter-specific meaning beyond what the schema provides. It mentions 'pending approval request' which implies the request must be pending, but that's a general context, not a parameter detail. Given high schema coverage, the 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: 'Approve or deny a pending approval request.' It uses a specific verb (approve/deny) and a specific resource (approval request), and it distinguishes this from sibling tools like atlasent_create_approval_request by focusing on resolving rather than creating. The purpose is unambiguous and easy for an agent to grasp.

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 the tool (when you need to resolve a pending approval request), but it does not explicitly mention alternatives or when NOT to use it. For instance, it does not say 'use this instead of atlasent_verify_permit' or caution against using it when the request is not pending. The guidance is implicit rather than explicit, which is adequate but not fully developed.

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 states the permit becomes invalid, indicating a destructive operation. But annotations have destructiveHint: false, contradicting the description. Therefore score is 1 due to 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?

Two sentences, each adding value. First sentence states purpose, second adds behavioral detail. 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?

For a simple revocation tool, the description covers main purpose and effect. Could include more about error conditions or prerequisites, but overall adequate given low 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 100%, so baseline is 3. The description does not add any additional meaning 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 the verb 'revoke', the resource 'permit', and the effect (immediately invalid for verify_permit). It distinguishes from siblings like atlasent_permit and atlasent_verify_permit.

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?

Description says 'Revoke a permit before it expires', providing context for when to use it. However, it does not explicitly mention when not to use it 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 indicate mutation (readOnlyHint=false) and not destructive. The description adds return structure and error condition (409), but does not detail side effects of sending a test event.

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-load the action and return info with no unnecessary words. Perfectly concise.

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 one-param test tool, the description is quite complete: action, return format, error case. Missing details about test event content are acceptable.

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 org_id with 100% description coverage. The tool description does not add any additional parameter meaning 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 the tool sends a test event to the SIEM destination and reports the result, with specific verb and resource. It is distinct from sibling SIEM 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 does not explicitly state when to use this tool vs alternatives like atlasent_get_siem_config. The 409 return code hints at post-configuration use, but no direct 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 indicate non-read-only and non-destructive behavior. The description adds important detail about partial updates and lifecycle transitions (publish/archive), which is beyond the annotations. 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 totaling 20 words, front-loaded with verb and resource. No redundant information. Efficient and to the point.

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 has 12 parameters and no output schema, the description covers the core purpose and partial update behavior. However, it lacks details on required parameters (policy_id, org_id) and expected return format, though schema provides parameter details. Adequate for a simple update 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%, so baseline 3. The description mentions parameters generically (rules, title, publish/archive) but doesn't add meaning beyond schema descriptions. No extra semantics for individual fields.

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

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

The description clearly states the tool updates a constraint bundle, with specific actions like changing rules, title, or publishing/archiving. It distinguishes from sibling tools like create, delete, and get by focusing on modification.

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 notes partial update semantics ('Only fields you provide are updated; omitted fields are unchanged.'), which is crucial for correct usage. While it doesn't explicitly list when not to use, the context of sibling tools implies it's for modifying existing policies.

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 mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds key behavioral details: 'destinationUrl must be HTTPS' (constraint) and 'credential is stored securely and never returned by GET' (security). This enriches 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?

Three concise sentences. First sentence states purpose, second adds requirement, third adds constraints and security. No wasted words, front-loaded with the most important 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?

With 9 parameters and no output schema, the description covers plan requirements, URL constraints, and credential security. It does not describe return behavior (which an upsert might provide), but given no output schema, this is acceptable. Overall complete for an upsert 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%, but the description adds meaning by specifying 'Enterprise plan required' (global context), 'destinationUrl must be HTTPS' (specific constraint), and 'credential stored securely...' (security semantics). These go beyond the schema's parameter descriptions.

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 or update') and resource ('SIEM export configuration') with scope ('for an organization'). It effectively distinguishes from sibling tools like 'atlasent_get_siem_config' (read-only) and 'atlasent_test_siem_delivery' (test only).

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 mentions the prerequisite ('Enterprise plan required'). It does not provide explicit when-not-to-use or alternatives, but the context is clear for creating or updating SIEM config. No direct comparison with siblings is 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. The description adds security-relevant framing (execution boundary, bypass risk) but does not disclose failure behavior such as whether verification fails open or closed, or what the tool returns.

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, both load-bearing: the first states purpose, the second states when to use and the security rationale. There is no filler, redundancy, or repetition of schema content.

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 security-critical verification tool with no output schema, the description covers purpose, usage boundary, and risk adequately. However, it omits return shape and failure/error semantics, which an agent would need to handle a rejected or invalid permit 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%, so the baseline is 3 with the schema doing the heavy lifting. The description adds only a general emphasis that 'full binding inputs' matter and under-specification is risky, without giving parameter-specific meaning 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 first sentence names a specific verb and resource — 'Verify a permit token' — and adds meaningful qualifiers ('full binding inputs', 'V1 endpoint'). The V1 reference implicitly distinguishes this from the sibling verify_permit, though it does not name the alternative explicitly.

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

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

Gives an explicit when-to-use instruction: 'at the execution boundary before the governed native effect', and explains the consequence of misuse ('under-specified verification is a bypass vector'). It provides clear context but does not name alternatives or 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?

The description adds behavioral context beyond annotations: it specifies the data source ('BCCAE compliance report') and the included data elements, which is valuable for understanding what the tool returns. 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 sentences with no unnecessary words. The first sentence states the purpose, the second provides a use case. 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?

Without an output schema, the description hints at return values (hash match rates, drift event counts, verdict changes), which is helpful. The tool is simple with 3 parameters, and the description adequately covers purpose and usage. However, for complete coverage, more detail on the return format could be beneficial.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description does not add new semantics to the parameters beyond their names and types.

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 'retrieve' and the resource 'summary of VQP audit activity' with explicit data points (hash match rates, drift event counts, verdict changes). It distinguishes itself from sibling tools like atlasent_vqp_drift_events by indicating this is a summary from the BCCAE compliance report.

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 a clear use case ('SOC 2 evidence collection and monitoring dashboards'), implying when to use. However, it does not explicitly state when not to use or compare to alternatives like atlasent_vqp_drift_events or atlasent_list_audit_events.

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, so the description's statement of listing snapshots adds behavioral context. It discloses the drift criteria beyond annotations, which is useful, though no extra details on auth or rate limits are given.

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, front-loaded with the action and resource, followed by purpose. 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 is a read-only listing with 4 parameters (all documented) and no output schema, the description adequately specifies what it returns and the criteria. It mentions the specific drift thresholds and usage context, which is complete for such a 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%, so parameters are fully documented. The description adds no additional parameter details beyond the schema; it implies filter criteria (drift/verdict change) but doesn't explain how parameters relate to these criteria.

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 VQP snapshots with specific drift criteria (≥10 points or verdict change), distinguishing it from sibling tools like atlasent_vqp_generate or atlasent_vqp_audit_summary by focusing on drift events.

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

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

It explicitly mentions use for compliance investigation and QA-VQP-002 §7 deviation reporting, providing clear context. It does not explicitly exclude other uses or compare to alternatives, but the purpose is well-defined.

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 non-read-only and non-destructive behavior. The description adds context by stating that a snapshot is stored and requires specific environment variables. However, it does not elaborate on potential side effects, idempotency, or data retention policies, leaving some behavioral aspects undisclosed 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 two sentences, front-loading the primary action. Every sentence provides necessary information with no extraneous content. The format is efficient and clear.

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 explains the core action and verdicts but lacks detail on the output format or return value. It does not document the vqp_context parameter's usage. Given moderate complexity and no output schema, the description is adequate but leaves gaps that could hinder an agent's 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 coverage is 100%, so the baseline is 3. The description adds overarching context about VQP criteria and verdict thresholds but does not provide additional parameter-specific meaning beyond the schema. It does not explain how vqp_context is used or what values it should contain.

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 scores a constraint bundle against six specific VQP criteria and stores a tamper-evident snapshot. It uses specific verbs ('Score', 'Stores') and identifies the resource ('constraint bundle', 'vqp_snapshots'). However, it does not differentiate this tool from sibling VQP tools like atlasent_vqp_audit_summary or atlasent_vqp_verify.

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 no guidance on when to use this tool versus alternatives. It lacks explicit context for when the tool is appropriate, prerequisites beyond environment variables, and does not mention any exclusionary or comparative criteria.

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 readOnlyHint=false and destructiveHint=false but are generic. The description adds significant transparency: it discloses that the tool writes an audit log, optionally makes an AI call (10-20s slower), and detects tampering and drift. 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?

Four concise sentences, all essential. The main action is stated first, followed by detection capabilities, optional behavior, logging, and requirements. No filler or 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?

Despite no output schema, the description mentions key outputs (hash_match, score_delta, verdict_changed, audit log row). It covers auth requirements and optional behavior. Could explicitly state return format but is sufficient for an agent to understand outcomes.

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 detailed descriptions for both parameters. The description reinforces the optional AI re-run (rerun) and the source of snapshot_id, adding context beyond the schema (e.g., '10–20 s AI call' for rerun). This warrants a score above baseline 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 uses specific verbs ('re-derive', 'verify', 'detects', 'writes') and clearly identifies the resource (VQP snapshot). It explains the core verification of hash_match and optional drift detection, distinguishing it from sibling tools like atlasent_vqp_generate and atlasent_vqp_audit_summary.

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 environment variables and implies use for tampering detection and SOC2/CFR compliance. It does not explicitly list when not to use or compare to alternatives, but the context is clear enough for a specialist 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 indicate readOnlyHint=false and destructiveHint=true, so the agent knows it is a mutating, destructive operation. The description adds context about the Permit verification process and that blocked calls never reach the target system, which is valuable behavioral transparency 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 with no extraneous words. The key point about the authorization gate is front-loaded, and every sentence contributes to understanding the tool's protected nature.

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 is complete regarding the authorization gating but lacks information about the actual deployment behavior, return values, or prerequisites like approvals. Given the destructive nature, an agent might need more context, but the schema covers parameters and the tool is described as an example.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no parameter-specific information, so it relies on the schema. A baseline of 3 is appropriate given the high 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?

The name and title clearly indicate a deployment action, and the description confirms it is a protected deploy operation. It distinguishes from sibling atlasent_* policy/audit tools, but the description focuses on the authorization gate rather than the deploy action itself, so the purpose is not fully 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention that this is the tool for deploying services or any prerequisites such as approvals. The description only discusses the authorization mechanism, leaving the intended use case to be inferred.

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=true, destructiveHint=false), the description adds the three-way decision semantics and the requirement to verify the returned permit_token before proceeding. It does not clarify token lifecycle details like single-use or expiry, but the core behavioral contract is well disclosed.

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 dense sentence that front-loads the invocation timing and packs the full decision contract into a compact, scannable structure. There is no filler or repetition of schema content.

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 no output schema, the description appropriately explains the three possible return values and the required post-call verification step. It omits edge-case behavior (e.g., error handling or token validation mechanics), but is sufficiently complete for a single-action evaluation gate.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description adds no extra parameter-level guidance, which is acceptable given the schema does the heavy lifting.

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

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

The description states a specific action ('Call this BEFORE performing any sensitive action') and the return contract (allow/deny/hold), making the tool's purpose clear. However, it does not differentiate this tool from the sibling tools atlasent_evaluate_many or atlasent_evaluate_stream, so an agent may not know which evaluator to select based on description alone.

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

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

It gives a concrete trigger ('BEFORE performing any sensitive action') and explicit follow-up behavior for each decision branch (verify permit_token at the execution boundary, MUST NOT proceed on deny, route for review on hold). It does not mention exclusions or when to prefer batch/stream 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by describing the `valid` field and enumerating outcomes that should block the action (expired, invalid, replayed, mismatched, error), which is useful 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, front-loaded with the critical sequencing instruction, and every sentence adds value. No filler or 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 there is no output schema, the description adequately conveys the return contract (a `valid` flag) and the possible outcomes. It also provides the workflow context that makes the tool's role clear. For a tool with this complexity and full schema parameter coverage, the description is 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 100%, so each parameter is already documented. The tool description does not add any additional semantic meaning for the parameters themselves; it only references the overall execution context. Per the rubric, a baseline of 3 is appropriate when the schema fully covers the parameters.

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 (verify), the resource (permit), and the exact position in a workflow (after evaluate, before the protected side effect). It distinguishes itself from the sibling `evaluate` by specifying the sequencing, making the tool's role 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 instructs when to call this tool ('AFTER evaluate returns allow and BEFORE the protected native side effect') and what to do with the result ('Proceed only when valid is true; ... must block the action'). This gives an agent a precise usage condition and decision rule.

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