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

No annotations are provided, and the description does not disclose behavioral traits such as pagination, rate limits, or permission requirements. While it implies a read-only operation, details on output format or limits beyond the 'limit' parameter are missing.

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

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

The description is concise with two sentences. The first sentence front-loads the primary purpose, and the second adds detail without redundancy. Every sentence is necessary.

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 or annotations, the description covers the basics but lacks details on ordering, environment scope, or whether entries are paginated. It is minimally adequate for a simple list tool.

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

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

The schema has 100% coverage for the single 'limit' parameter, which is clearly described there. The description does not add extra meaning 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's purpose: viewing the audit log of secret resolutions, stores, and deletes. It specifies the information shown (who accessed which secret and when), making it distinct from sibling tools like store_secret or list_secrets.

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 audit purposes but lacks explicit guidance on when to use this tool versus alternatives. No 'when-not-to-use' or specific conditions are mentioned, leaving room for ambiguity.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the secret is encrypted client-side into the URL fragment and never sent to a server, and that links expire. However, it omits auth requirements, what the return value looks like (no output schema exists), and what happens when ttl or maxViews limits are hit.

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 compact sentences, with the security-relevant detail front-loaded after the core purpose. Every sentence earns its place and there is no padding.

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

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

For a simple three-parameter tool whose schema is fully documented and that returns a link, the description covers the essential mechanics and the non-obvious privacy property. It could be stronger with a note on prerequisites and return format, but it is nearly complete for this complexity 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 description coverage is 100%, so the schema already documents name, ttl, and maxViews with defaults and formats. The description adds only the concept of expiry and does not elaborate on parameter behavior beyond the schema. Baseline 3 applies when 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?

States a specific verb and resource ('Create an encrypted, expiring share link for a secret') and adds the key security property that the secret lives in the URL fragment. An agent can tell this apart from sibling tools like resolve_secret or receive_share, though the description does not explicitly name a sibling alternative.

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 implied by the phrase 'share link for a secret', but there is no explicit when-to-use or when-not guidance relative to siblings such as receive_share or resolve_secret. There is no mention of prerequisites like the secret already existing in the store.

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?

No annotations and no output schema, so the description carries the full burden and does not meet it. It never states what happens when the timer expires, whether the reset is idempotent, whether authentication is required, or what the call returns — the consequences of the switch firing are the core behavioral fact and they are absent.

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?

A single tight sentence with no filler and the action front-loaded. It is efficient, though the brevity comes at the cost of the missing behavioral detail noted elsewhere.

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

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

For a zero-parameter mutation tool the description is minimally adequate: the agent knows what calling it does at a high level. It is incomplete regarding expiry consequences and the relationship to deadman_status, which an agent would reasonably need before wiring this into a heartbeat routine.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter claims are made that could mislead.

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

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

States a specific verb ('check in') and the resource it acts on ('dead man's switch timer'), so the agent knows this resets a timer. It does not differentiate from the sibling deadman_status, leaving the read-vs-reset distinction to the tool names 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?

No guidance on when to call it: no check-in cadence, no deadline semantics, and no mention of the sibling deadman_status for inspecting state first. The agent must infer usage entirely from the phrase 'dead man's switch'.

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?

With no annotations, the description carries the full behavioral burden; 'Check' implies a read-only operation and it discloses the core return semantic (days until release). It says nothing about authorization requirements, what the status looks like at zero or after release, or whether checking affects the timer, which matters for a safety-critical switch.

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?

A single front-loaded sentence with the resource first and the return meaning second; no filler, nothing that could be cut without losing 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 zero-parameter read tool this is close to sufficient, and it compensates for the missing output schema by naming the return value. However, it omits the possible status states, what a released switch reports, and how it relates to deadman_checkin, leaving an agent to guess at the edges.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies the target vault/agent is implicit in the caller's identity.

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 ('Check dead man's switch status') and adds the key semantic ('days until vault access is released to designated contacts'), so an agent knows exactly what is being read. It stops short of differentiating from the sibling deadman_checkin, which is easy to confuse with a status query.

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?

There is no statement of when to use this versus deadman_checkin or what conditions make status checking appropriate. With a near-identically named sibling in the toolset, the absence of routing guidance is a real gap.

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?

With no annotations, the description carries the full behavioral burden and fails to disclose that deletion is presumably irreversible, that authentication is required via token or agentId+signature scheme, or what happens if the named secret does not exist. The only behavior stated is the bare mutation itself.

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 single sentence is front-loaded and free of waste, but it is undersized for a six-parameter, auth-gated destructive operation. Brevity here reads as under-specification rather than efficiency.

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 destructive mutation with six parameters, a signed-access auth scheme, no annotations, and no output schema, one sentence is far from sufficient. An agent gets no warning about permanence, auth requirements, or error behavior.

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 six parameters (including the signature/nonce/exp auth scheme) are already documented in the schema. The description adds nothing about the 'name' parameter or the auth alternatives, 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 and resource: 'Delete a secret from the vault.' An agent can tell it apart from store_secret and resolve_secret without opening schemas, though it says nothing about scope or whether deletion is permanent.

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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to siblings such as list_secrets (to identify the name) or resolve_secret. The agent must infer everything about 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?

No annotations are provided, so the description carries the full burden. It does not state that the export is read-only, what scope of ledger is covered (all agents? caller only?), whether a time window applies, or whether an artifact/file is produced or persisted. Only the output content hint ('human-sponsor attribution') is 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?

One sentence, zero waste, with the resource and output format front-loaded. Nothing is padded or redundant.

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

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

With no output schema and a mutation-adjacent export operation, the description should clarify the report's scope and contents. Notably there is no time-range parameter, yet the description never says what period or population of actions is exported, leaving a real gap for a compliance use case.

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 single enum parameter already documents json/csv with a default. The description merely restates the format options, adding no new semantics such as default behavior or format-specific differences (e.g., CSV flattening of attribution 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?

Specific verb+resource: 'Export the agent action ledger as a compliance report' with explicit formats. It does not distinguish itself from closely related siblings such as audit_log or verify_ledger, so it stops short of a 5.

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

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

The phrase 'compliance report' hints at the use case, but there is no explicit when-to-use, no when-not-to-use, and no mention of audit_log or verify_ledger as alternatives. An agent facing both this and audit_log gets no routing signal.

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?

No annotations are provided, so the description carries the full burden and discloses almost nothing: no indication of whether the listing is paginated, whether it requires authentication, whether it includes deregistered agents, or what the response looks like. "All" is the only behavioral hint.

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?

A single short sentence with zero waste, front-loading the verb and resource. Nothing is padded or repeated.

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 zero-parameter list tool this is close to adequate, but with no annotations and no output schema the agent gets no picture of the return shape or result volume. One clause about what each entry contains or whether results are bounded would close the gap.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; baseline 4 applies. The description correctly implies an unfiltered listing consistent with the empty 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?

States a specific verb and resource ("List all agents") and scopes it to the Know Your Agent registry, which distinguishes it from the CRUD siblings like register_agent. It does not explicitly name an alternative, but the read-only enumeration purpose is unambiguous.

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

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

There is no when-to-use statement, no prerequisite (e.g. registration or auth), and no mention of alternatives or follow-up tools such as register_agent. The word "all" implies no filtering, but the agent must infer everything else.

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?

No annotations exist, so the description carries the full burden. It does disclose one genuinely valuable trait — that values are never returned — but says nothing about the auth model (token vs. signed agentId request with nonce/exp/signature), which is the dominant complexity of this tool.

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?

A single tight sentence with the scope constraint front-loaded and no filler. Nothing could be removed without losing 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?

Adequate for a simple read-only listing, and the names-only constraint is the key fact. But with no annotations and no output schema, leaving the authentication requirements entirely to the schema makes the definition thinner than ideal for a tool with five credential parameters.

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

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

All five parameters have schema descriptions (100% coverage), so the schema already documents them. The description adds no additional meaning about how exp/nonce/signature must be paired with agentId or when token is the preferred path, so it stays at baseline.

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

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

States a specific verb and resource ('List all stored secret names') and adds a decisive scope qualifier: names only, values never revealed. That distinguishes it from value-retrieving siblings like resolve_secret, though it never names them 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?

No when-to-use guidance and no mention of alternatives such as resolve_secret or audit_log, even though those are the obvious adjacent tools. The 'names only' note implies it's for discovery, but the agent must infer that.

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?

No annotations are provided, so the description must carry the behavioral burden. It discloses decryption but omits important side effects (e.g., whether the secret is stored locally), permission requirements, and return format—critical gaps for a secret-handling tool.

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?

A single, front-loaded sentence that immediately communicates the action, resource, and input source with zero waste.

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, the description covers the core operation but leaves out the return value (no output schema exists) and whether the secret is persisted, which an agent would need to know.

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 both parameters are fully documented. The description adds no extra meaning beyond the schema's existing explanations, which is baseline-adequate.

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 ('Receive and decrypt') and resource ('shared secret') with a clear source ('from a share URL fragment'), making it easy to distinguish from sibling tools like create_share_link.

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 clear context for use: when you have a share URL fragment. It does not explicitly name alternatives or exclusions, but the condition is sufficient for an agent to select it over siblings.

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

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

With no annotations, the description carries the full burden and delivers meaningful behavioral context: entries are hash-chained and Ed25519-signed, and tampering downstream is detectable. It omits the practical implications an agent needs — that the write is permanent/append-only, and that a sensitive private key is required — but the security model is unusually well disclosed for a no-annotation tool.

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 with no waste. The core action is front-loaded and the security rationale follows immediately, earning its place by explaining why the tool exists.

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 5-parameter mutation with no annotations and no output schema, the description explains the integrity model but not the return value — an agent cannot tell whether it receives a hash, sequence number, or the entry itself. It also doesn't clarify that the appended entry is irreversible or what happens if the signature fails, leaving notable gaps for a write 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 all five parameters, including the privateKey base64 format and metadata JSON string, are already documented. The description adds only indirect meaning by tying signing to the private key and 'action' to ledger entries, 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?

States a specific verb and resource: 'Append a signed action to the tamper-proof agent ledger.' That clearly distinguishes it from verify_ledger and audit_log by direction (write vs read). It stops short of explicitly naming the sibling it complements, which keeps it out of the top band.

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?

Use is implied by 'append ... to the ledger' and by the schema note that agentId comes from register_agent, which hints at the precondition of registering first. However, it never says when to choose this over audit_log or verify_ledger, and no explicit exclusions or prerequisites are given in the description itself.

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?

With no annotations, the description carries the full load, and it does disclose the most consequential behavior: this tool returns an Ed25519 private key that the agent holds to sign its own actions — a one-time sensitive credential the caller must handle. It stops short of stating whether the key is shown only once, whether registration is idempotent for the same name, or what permissions are required.

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

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

Two sentences, zero filler, with the core action and the security-critical return value front-loaded. 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?

There is no output schema, so the description must explain return values — and it does (agent identity plus private key). Parameter semantics are fully covered by the schema. The only gap for a credential-minting mutation tool is handling guidance around the returned key.

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 name, scope, and sponsor are already fully documented with examples in the schema. The description adds only that the agent is 'bound to a human sponsor', restating rather than extending the schema, so 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 names a specific verb and resource — 'Register an AI agent in the Know Your Agent registry' — plus the binding constraint (human sponsor) and what is returned (identity + Ed25519 private key). It is clearly not a read/list tool, so an agent can distinguish it from list_agents without opening the schema, though no sibling is named 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?

The registration intent is implied well enough that an agent knows this is the creation path, and 'bound to a human sponsor' hints at a prerequisite. However there is no explicit when-to-use vs when-not, no statement about who must authorize registration, and no guidance on what to do afterwards (e.g., list_agents to confirm).

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?

With no annotations provided, the description carries the full burden and discloses important behavior: it returns a decrypted value at runtime and asserts that the value is never visible in the LLM conversation transcript. It does not cover authentication requirements, audit behavior, or failure modes, which keeps it below a 5.

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

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

The description is three tight sentences with the core action front-loaded and no wasted language. Each sentence contributes either purpose, return behavior, or the security-relevant transcript guarantee.

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 six-parameter, security-sensitive resolution tool with no output schema and no annotations, the description explains the high-level return and secrecy behavior but omits how token/agentId/signature authentication modes interact. The rich schema mitigates this, but the description is only minimally 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 description coverage is 100%, so the schema already explains parameters such as token, agentId, signature, nonce, and exp. The description only reinforces the "name" parameter and adds no meaningful semantics beyond the schema, making the baseline 3 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 ("Resolve a secret by name") and identifies supported backends, making the core purpose clear. It does not explicitly distinguish this tool from siblings such as list_secrets or team_resolve, so it stops short of full sibling differentiation.

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 runtime use by saying the secret is "resolved just-in-time for the current operation," but it gives no explicit when-to-use guidance, exclusions, or comparison against alternatives like list_secrets or team_resolve. Usage is inferable but not directly specified.

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?

Without annotations, the description discloses key behaviors: encryption and backup of real values to vault, and that AI agents only see fakes. However, it lacks details on vault storage details or permissions, but is generally transparent.

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: first states the action, second explains consequences and sibling tool. 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 mutation tool with one optional parameter and no output schema, the description covers purpose, behavior, and complementary tool. Complete enough for correct 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?

Only one parameter (filePath) with a schema description. The tool description adds no extra semantic beyond the schema's own description, so baseline 3 applies given 100% schema coverage.

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

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

The description clearly states the tool's action: replace real .env values with deterministic fakes, encrypt and backup real values, and AI agents see fakes. It distinguishes itself from the sibling unsandbox_env.

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 tells when to use this tool (to sandbox .env values) and when not (use unsandbox_env to restore real values), providing clear context and an alternative.

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?

With no annotations, the description carries the full burden. 'Check' implies a non-mutating read, which is a small signal, but nothing is said about required credentials, whether it makes a network call to the identity provider, what the status actually contains (configured vs. enabled vs. provider metadata), or how failures/absence of SSO are reported.

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?

A single front-loaded sentence with no filler — the resource and scope appear immediately. It is efficient, though it errs toward under-specification rather than maximum information density.

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?

Zero parameters keeps the calling contract trivial, but there is no output schema, so the description is the only place a reader could learn what 'status' means in the response — and it does not say. Adequate to call the tool, insufficient to interpret it.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description correctly implies no inputs are needed to perform the check.

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?

Specific verb ('Check') plus specific resource ('SSO/OIDC authentication status') with the scope limited to 'team vault access'. No sibling in the list performs an SSO status check, so the tool is functionally distinguishable, though the description never explicitly contrasts itself with team_init or team_resolve.

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 phrase 'for team vault access' implies the context in which to reach for it, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g., team_init for configuring SSO). Usage must 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?

With no annotations at all, the description carries the full burden, and it does disclose real behavior: AES-256-GCM encryption at rest and that the value will not appear in the transcript afterward. However, it says nothing about overwrite semantics for an existing name, permission/scope-enforcement failures, or whether the call is reversible, which matter for a write operation with a complex auth model.

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

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

Three short sentences, front-loaded with the core action, with no filler. The encryption and transcript sentences both add value, though the transcript point is the more useful of the two for an agent deciding what to pass in.

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 seven-parameter mutation with a non-trivial signed-auth model and no annotations or output schema, the description leaves the agent without any explanation of the authentication options or the result of the call. The security posture is well covered, but the operational picture is not.

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 seven parameters, including the signed-access trio of agentId/nonce/exp/signature, are already documented in the schema. The description adds no meaning beyond that baseline, so a 3 is the correct ceiling.

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 and resource ("Store a secret in the encrypted vault"), which cleanly separates it from resolve_secret, list_secrets, and delete_secret without needing to name them. It stops short of explicitly contrasting with those siblings, but the operation is 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?

There is no guidance on when to use this versus alternatives, no mention of prerequisites such as registering an agent first, and no hint about which of the two auth paths (token vs. agentId+nonce+exp+signature) an agent should take. The agent must infer all of this from the schema.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool deletes a secret, implying a destructive mutation, but does not describe irreversibility, permission requirements, failure modes, or whether deletion is permanent.

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 front-loaded sentence with no wasted words. It is efficient, though its brevity reflects under-specification rather than optimal 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?

This is a destructive mutation tool with no annotations and no output schema. The description does not explain what happens on success or failure, whether deletion is reversible, or what permissions the passphrase grants. For a team-vault deletion operation, that leaves important context 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?

Schema description coverage is 100%, and both parameters are clearly documented in the schema. The description adds no additional parameter meaning beyond the schema, 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: delete a secret. It also scopes the resource to the team vault, which helps distinguish it from sibling tools like delete_secret. However, it does not explicitly name alternatives or state that it is not for non-team secrets.

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 such as delete_secret or team_resolve. It does not mention prerequisites, exclusions, or the required passphrase context beyond what the schema already states.

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?

With no annotations, the description carries the full burden, and it does disclose two useful traits: the vault is encrypted SQLite and a passphrase is mandatory. It omits critical creation semantics — whether an existing file at `path` is overwritten or errors out, whether the operation is destructive, and what a successful call 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 short sentences, zero filler, with the core action front-loaded and the requirement trailing. 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 two-parameter creation tool with no output schema and no annotations, the description covers what it makes and what it needs. The one meaningful gap is overwrite/error behavior for an existing path, which matters for a file-creating 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 both `path` and `passphrase` are already documented in the schema. The description reinforces the passphrase requirement but adds no syntax, format, or constraint details beyond 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?

States a specific verb and resource ('Create a new shared team vault'), plus the storage format (encrypted SQLite). This clearly separates it from sibling operations like team_push, team_pull, team_list and team_delete, though it never names those siblings as alternatives.

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 only usage signal is the prerequisite 'Requires a passphrase.' There is no statement of when to call this versus listing existing vaults (team_list) or when not to call it, so the agent must infer placement in a workflow.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only listing and clarifies that only secret names are returned, but it does not describe authentication behavior beyond the schema's passphrase parameter, permissions, rate limits, pagination, or error behavior.

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

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

The description is a single front-loaded sentence with no redundant or wasted language. It immediately states the resource and scope.

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-parameter listing tool, the description is minimally adequate: it identifies the resource and clarifies that names, not values, are returned. However, without annotations or an output schema, it leaves gaps around authentication expectations, usage alternatives, and listing behavior.

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

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

There is one parameter and schema description coverage is 100%, so the schema already documents the required passphrase. The description does not add meaning beyond the schema, which matches the baseline for high schema coverage.

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

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

The description gives a specific verb and resource: it lists secret names in the team vault. It is clear what the tool does, but it does not explicitly distinguish itself from related siblings such as list_secrets or team_resolve.

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 what the tool does but provides no guidance on when to use it instead of list_secrets, team_resolve, or other vault-related tools. There are no exclusions, prerequisites, or alternative-selection 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?

With no annotations, the description carries the full behavioral burden but only says it imports all secrets. It does not disclose whether existing local secrets are overwritten or merged, what permissions or passphrase errors may occur, or what happens on failure, which are critical for a bulk mutation operation.

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?

A single, front-loaded sentence that states the action and direction without any waste. It is appropriately sized for a tool with one clearly scoped purpose.

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

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

For a security-sensitive bulk import with no annotations and no output schema, the description is too thin. It omits critical context about overwrite behavior, conflict handling, and expected results, leaving the agent unable to fully predict the tool's effects.

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

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

The single passphrase parameter is fully documented in the schema (100% coverage), so the schema already explains it. The description adds no additional meaning beyond the schema, making the baseline 3 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?

States a specific verb (import) and resource (all secrets) with a clear direction from team vault to local vault. This inherently contrasts with the sibling team_push, though no sibling is explicitly named.

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 no guidance on when to use this tool versus alternatives such as team_push, team_list, or team_resolve. It only implies usage from the operation itself and provides no prerequisites, exclusions, 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?

With no annotations, the description carries the full burden for a mutation tool and delivers little: it does not say whether an existing remote secret with the same name is overwritten, what happens on a bad passphrase, whether team membership/permissions are required, or whether the push is reversible. Only the direction of data flow is 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?

One short, front-loaded sentence with zero waste and the action verb first. It is efficiently structured, though the brevity reflects under-specification rather than disciplined editing.

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 write operation into a shared vault with no annotations and no output schema, the description omits prerequisites, overwrite/conflict behavior, error conditions, and any hint of the return value. An agent could invoke this correctly by schema alone but would not understand its consequences.

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 three parameters are already documented, including the note that omitting value resolves from the local vault. The description's phrase 'a local secret' is loosely consistent but adds no format, naming, or passphrase semantics beyond 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?

States a specific verb and resource with direction: pushing a local secret into the shared team vault. The directional verb implicitly contrasts with the sibling team_pull, but no sibling or scope boundary is named 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?

There is no guidance on when to use this versus team_pull, team_resolve, store_secret, or create_share_link, nor any stated prerequisites such as the team vault needing team_init or a valid passphrase. The agent must infer the entire selection 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?

Since no annotations were provided, the description carries the entire burden of behavioral transparency. It offers no information regarding potential failure modes, rate limits, or the specific security implications of using the passphrase, making it highly opaque.

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 definition uses a single sentence to succinctly convey the tool's core function without any unnecessary verbiage or bloat, making it 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?

While the tool is simple (2 params, no output schema), the lack of guidance on its usage relative to other retrieval tools, and the missing behavioral context for a critical vault operation, prevent a higher score.

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 coverage is 100%, meaning the schema fully documents the parameters. The description adds no semantic value or contextual information that isn't already provided in the input schema definitions.

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 ('Resolve' or 'decrypt') and the target resource ('a single secret from the team vault'). It successfully defines the primary 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 provides zero guidance on when this tool should be used. Given the existence of sibling tools like `resolve_secret` or `list_secrets`, the definition fails to specify any operational context or constraints for its use.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return format and rotation window, but it does not state failure behavior when the stored secret is missing, security sensitivity, or whether the operation has any 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 tight sentences with zero wasted wording. It front-loads the core action and then adds the return behavior.

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-parameter tool with full schema coverage and no output schema, the description is largely complete and explains the returned code format and remaining seconds. It is only missing minor operational context such as what happens when the named TOTP configuration is absent.

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 single name parameter is already documented. The description adds only the phrase 'for a stored secret,' which aligns with the schema without adding format or validation detail beyond it.

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: generate a TOTP 2FA code for a stored secret. It clearly distinguishes this code-generation action from sibling secret-management tools such as totp_store, totp_list, and totp_delete.

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 implied: use this when a current TOTP code is needed from a stored configuration. However, the description does not explicitly name when to use it versus siblings or state exclusions, such as not using it to create or list TOTP configurations.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not state whether deletion is permanent/irreversible, whether confirmation is required, what happens if the name doesn't exist, or what the response contains — critical unknowns for a destructive mutation.

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?

A single front-loaded sentence with zero waste. It is appropriately sized, though its brevity is also the source of the missing behavioral detail.

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

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

For a destructive, no-annotation tool with no output schema, the description is too thin. An agent cannot tell whether the deletion is recoverable, whether it affects active sessions, or how failures are surfaced.

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 the single 'name' parameter, and the description adds nothing beyond it. Per the baseline rule, a 3 is appropriate when the schema fully documents 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?

Specific verb ('Delete') plus specific resource ('stored TOTP configuration') makes the operation unmistakable. The verb alone distinguishes it from siblings like totp_store, totp_list, and totp_code, though the description never names those alternatives 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?

No guidance on when to delete versus revoke or regenerate a TOTP config, and no prerequisites or warnings. The agent must infer the use case entirely from the verb.

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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond 'list'. It does not say whether TOTP secrets are returned in the response (a real sensitivity question for this resource), nor anything about ordering or result size.

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?

A single six-word sentence that front-loads the verb and resource with zero filler. Nothing is padded or restated.

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-argument list tool with no output schema and no annotations, the description is the sole source of behavioral information, and it omits whether secret material is exposed and what shape results take. Adequate to call, but not complete for a security-sensitive tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The word 'all' usefully confirms there are no filtering options to supply.

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?

Specific verb (List) plus resource (stored TOTP configurations) with the scope word 'all' making clear it is an unfiltered enumeration. It implicitly distinguishes itself from totp_code (generates a code) and totp_store (writes), though it never names those siblings 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?

Usage is only implied: an agent can infer this is the discovery/enumeration call before totp_code or totp_delete. There is no explicit when-to-use statement and no guidance on prerequisites versus the other totp_* siblings.

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

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

With no annotations, the description carries the full behavioral burden, and it only says "Store." It does not state whether an existing config with the same name is overwritten, whether the secret is validated or encrypted at rest, whether auth is required, or what is returned. For a mutation tool with zero annotation coverage this is a notable gap.

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?

A single front-loaded sentence with the verb and resource first and no wasted clauses. Nothing in it could be removed without losing 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?

A write tool with no annotations and no output schema needs the description to cover collision/overwrite behavior, secret handling, and error conditions, none of which appear. The schema documents the inputs, but the behavioral surface is largely unexplained.

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 both parameters are documented inline, so the baseline is 3. The description adds only that the URI originates from a QR scan or manual entry, which is marginal context beyond the schema's own wording.

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?

Specific verb ("Store") plus resource ("TOTP configuration") and input format ("otpauth:// URI"), which clearly separates it from totp_list, totp_delete and totp_code. It stops short of naming any sibling explicitly, so differentiation relies on inference from the verb.

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 parenthetical "from QR code scan or manual entry" gives a hint about when the tool applies, but there is no explicit when-to-use vs when-not guidance and no mention of alternatives such as store_secret or totp_code. Usage is implied rather than stated.

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?

No annotations are provided, so the description carries full burden. It states it restores real values and reverses sandbox, but lacks details on what 'restore' entails (overwrites file? requires vault access?), side effects, or return behavior.

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

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

Two sentences, no wasted words. However, it may be too concise given missing behavioral details. Still earns the score for being 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 tool with one optional parameter and a clear sibling (sandbox_env), the description provides the basic purpose but lacks behavioral context and usage guidelines. Minimally adequate.

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% (one parameter fully described). The description does not add any additional meaning beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the action ('restore real .env values from the vault') and the resource ('.env values'). It distinguishes from siblings by mentioning 'reverses the sandbox operation', implicitly linking to sandbox_env. However, it doesn't explicitly name the sibling 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?

No explicit guidance on when to use this tool versus alternatives. It only states it reverses the sandbox operation, but does not mention prerequisites (e.g., must have sandboxed first) or when not to use.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool re-walks the hash chain and signatures and returns the first failing sequence when tampering is detected, but it does not state the success return value, side effects, permissions, or cost.

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 tight sentences with no wasted words. It front-loads the primary action and follows with the mechanism and failure behavior.

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 zero-parameter verification tool, the description covers the operation and the failure return behavior. Because there is no output schema, it could more fully specify what a successful verification returns, but the core invocation context is present.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The empty schema is consistent with the description, and the baseline for a zero-parameter tool is 4.

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

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

The description uses a specific verb and resource: verify the integrity of the agent action ledger. It also explains the mechanism, re-walking the hash chain and signatures, which clearly distinguishes this tool from ledger-writing or audit-reading siblings such as record_action and audit_log.

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 implied by the purpose: use this tool to check ledger integrity and detect tampering. However, the description does not explicitly say when to use it versus alternatives like audit_log or export_compliance, nor does it mention prerequisites or exclusions.

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