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

With no annotations, the description carries the full burden and does reasonably well: it discloses that the function is local and pure (no external side effects), that the result is ALLOW/DENY, and that cap_token is only included on allow when CAP_TOKEN_SECRET is configured. It omits error/deny-case behavior and any latency or determinism caveats.

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 dense sentences, front-loaded with the core purpose and followed by output behavior and the required follow-up call. Nearly every clause earns its place; the parenthetical HTTP equivalence is useful rather than 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 must describe returns and it partially does (ALLOW/DENY plus conditional cap_token). It remains incomplete on the undocumented `card` parameter and on failure modes, leaving gaps an agent would need to resolve before calling 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 0% across three parameters, so the description must compensate, and it only partially does. It restates the action enum and ties action to the downstream token flow, but the `card` parameter is never mentioned and the `cap` parameter's format or source is not explained.

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 (ALLOW/DENY) and resource (a published cap string for an action), and notes it is a local pure function equivalent to POST /cap-check, which helps an agent map it to a known HTTP operation. It does not fully define what a 'cap string' is, but the operation itself 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?

Gives one concrete conditional workflow rule: spend/send actions must subsequently call cap_token_check before the hop. However, it never explains when to prefer this over the sibling cap_preflight, nor when-not to use it, so routing between the two cap-related tools is left 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?

With no annotations, the description carries the full load and does well: it discloses fail-closed semantics, that allow + secret mints a cap_token, and that deny on spend/send returns isError/abort. It omits what happens for read/write/other actions and any auth/rate-limit context, 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?

Dense but front-loaded, with the mandatory nature and the fail-closed rule stated first. Nothing is padded, though the telegraphic style ('hop', 'checkCap') risks ambiguity.

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 complex gate tool with no annotations and no output schema, the behavioral flow is covered but key pieces are missing: the meaning of cap/card, what non-spend/send actions yield, and any indication of output shape. Adequate but short of complete.

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

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

Schema description coverage is 0% over 3 params, so the description must compensate and largely does not. It hints at the action enum ('spend|send') and mentions a 'secret' that does not even appear in the schema, but leaves 'cap' and 'card' entirely unexplained. This is a real gap.

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

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

States a specific role: a fail-closed preflight gate run before spend/send that wraps the capability check. This distinguishes it from siblings cap_check (the underlying check) and cap_token_check (the token validator), though the term 'checkCap' is jargon that assumes knowledge of the sibling.

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 it is MUST-run before spend/send, specifies the deny path (isError/abort, do not proceed), and routes the agent onward: 'Present token to cap_token_check before hop.' No when-not guidance, but the mandatory trigger condition is stated without 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses that the token is short-lived, that verification uses local secret env vars when available and otherwise POSTs to a remote endpoint, and that the behavior is 'Fail closed.' This is meaningful beyond the schema. It still omits return semantics and error specifics, so it falls short of 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?

Two compact sentences front-load the core purpose, then add fallback behavior and failure mode with no wasted words. The structure is efficient and appropriately sized for the 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?

For a three-parameter verification tool with no annotations and no output schema, the description is largely complete: it establishes purpose, required inputs, optional input, secret resolution, remote fallback, and fail-closed behavior. Remaining gaps around return values and exact error behavior are minor given the absence of an output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It identifies all three parameters (token, action, optional card) and adds that the token is short-lived and the card is optional. But it does not clarify what 'card' represents, expected token format, or how action values affect behavior, leaving gaps beyond the enum already present in 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 states a specific verb and resource: verify a short-lived cap_token for an action. This is clear enough for an agent to understand the operation. However, it does not distinguish itself from similar sibling tools such as cap_check, cap_preflight, or verify, 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 description gives no when-to-use or when-not-to-use guidance, and it names no alternatives among the closely related sibling tools. Usage is only implied by the verb 'Verify' and the mention of an optional card, which is insufficient for selecting between overlapping auth-check 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?

No annotations are provided, so the description carries the full behavioral burden. It reveals the HTTP method GET, implying a safe read, but does not disclose authentication requirements, rate limits, return format, or any other behavioral trait.

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 line with no filler. Every element (verb, resource, path) 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 zero-parameter read tool with no output schema, the description identifies the endpoint and method adequately. However, it omits enough behavioral context (auth, expected return content) that it falls short of fully compensating for the absent annotations and output schema.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to document parameters and adds no misleading information about them.

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 HTTP verb (GET) and resource (bot instructions /llms.txt). The resource is distinct from all sibling tools, so an agent can tell what this tool does without opening the schema.

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. The name and description imply a simple fetch, but no conditions, exclusions, or alternatives 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only implies a read via 'GET' and gives the endpoint; it says nothing about return format, authentication, pagination, or 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 a single terse phrase with no wasted words, but it is so minimal that it lacks useful structure and context. Conciseness is present, but the brevity comes at the cost of clarity.

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

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

Given no annotations, no output schema, and zero parameters, the description should explain what 'pending off-wall' means and what the response contains. It provides only an endpoint path, leaving key contextual information 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 tool takes zero parameters, so parameter semantics baseline is 4. The schema is empty, and the description's only parameter-adjacent detail is the endpoint path, which is not needed for parameter meaning.

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 HTTP verb and resource ('GET pending off-wall') plus the endpoint path. However, 'off-wall' is unexplained and it does not distinguish itself from sibling tools like wall_get, so the purpose is only moderately clear.

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 tool versus alternatives such as wall_get or trail_get. No prerequisites, context, or exclusions are provided.

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

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

With no annotations, the description carries the full burden, and it does disclose the post-write tier assignment logic (pending/test/self/verified), which is genuinely useful behavioral context. However, it omits mutation semantics, idempotency, auth requirements, and any side effects of writing a row.

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 dense sentences with no filler, front-loaded with the call shape. The tier-label enumeration is compact and information-bearing rather than 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 5-parameter mutation tool with no annotations and no output schema, the description is thin: it explains the resulting tier labels but leaves every parameter's semantics, prerequisites, and failure behavior undocumented.

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

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

Schema coverage is 0%, so the description must compensate. It names all five parameters and restates the non-empty-string constraint (already in the schema), but gives no meaning for card, job, proof, incident, or cap, leaving the agent unable to reason about what to pass.

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 an action (POST /room) and enumerates the five required inputs, so the mechanics are visible, but it never explains what a 'room' is or what resource is being created, leaving the actual purpose vague. It also doesn't distinguish itself from the similarly-named sibling room_post.

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 explicit when-to-use guidance or mention of alternatives. The tier-labeling rules hint that this participates in a verification workflow alongside verify/cap_check, but the agent is left to infer that routing entirely on its own.

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. POST implies a mutation, but the description does not disclose side effects, authentication needs, idempotency, response behavior, or what happens to existing data. It only adds the legacy-alias context, leaving most behavioral traits undisclosed.

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 compact sentence with no filler. It front-loads the alias/legacy relationship and route, though 'exactly five fields' is redundant with the schema and adds little value.

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

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

There is no output schema and no annotations, and the tool has five required parameters with no descriptions. The definition does not explain parameter meanings, usage context, or behavioral effects, so it is not complete enough for an agent to invoke it confidently.

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

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

There are five required parameters with 0% schema description coverage. The description only says 'exactly five fields' and does not name or explain any of them, so it fails to compensate for the schema's complete lack of parameter semantics.

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

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

The description identifies the route (POST /room) and says it is an alias of post, which gives some specific operation context. However, it does not explain what a room post is or what the tool actually accomplishes beyond being a legacy alias, so the purpose remains somewhat vague.

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 says 'kept for 0.4 configs,' which implies when this legacy alias should be used and hints that the sibling post is the modern alternative. It does not explicitly state when not to use it or name the alternative directly, so guidance is implied rather than complete.

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 implies a read-only HTTP GET and names the path, but discloses nothing about auth requirements, rate limits, caching, or failure modes for a tool with zero annotation coverage.

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?

It is short, but the brevity comes from under-specification rather than efficiency. The single cryptic phrase "GET join showcase path" is not front-loaded with a clear verb+resource statement, so every word fails to earn an informational 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 zero-param tool with no output schema, the description should at least say what /showcase.json returns or when it is the right call among the many *_get siblings. Neither is present, leaving the agent with only a raw 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?

The tool takes no parameters, so the schema and description agree that there is nothing to document. Baseline 4 applies for a zero-parameter tool; the description adds no parameter information because none is needed.

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

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

"GET join showcase path (/showcase.json)" largely restates the tool name (showcase_get) and adds only a literal endpoint path. The odd phrasing "join showcase path" leaves the resource and what is actually fetched ambiguous, so an agent cannot confidently distinguish its purpose from show_case-like siblings such as wall_get or trail_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 offers no when-to-use, when-not-to-use, or alternative routing. With ten sibling tools including other *_get endpoints (pending_get, wall_get, trail_get, llms_get), there is no signal about which situation selects showcase_get.

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 does disclose both outcomes: deny yields isError/spent:false with no hop, allow yields spent:true with an explicit 'no money' caveat. It adds real behavioral context (error signalling, non-financial side effect) though it omits any auth/permission or idempotency notes.

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?

Tight and front-loaded: the endpoint, payload, and outcome branch are stated in two dense sentences plus the prerequisite. Arrow notation is efficient, though the 'Week-2 demo hop' framing is slightly opaque 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 no-annotation, no-output-schema tool with three params, the description covers the prerequisite, the payload contract, and both success/failure returns. It is complete enough to invoke correctly, lacking only detail on the 'card' identifier semantics.

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

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

Schema coverage is 0%, so the description must compensate. It names all three params but only adds genuine meaning for cap_token (obtained from cap_preflight/cap_check) while 'card' and 'optional amount_note string' merely restate the schema without clarifying formats or accepted values.

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 the action (a demo spend via POST /spend-demo) and the payload shape (card + action:spend + cap_token). It also clearly distinguishes scope from siblings by naming cap_preflight/cap_check as the token source, though the term 'hop' is private jargon that adds little for an outside agent.

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

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

Gives an explicit prerequisite sequence ('Get token via cap_preflight/cap_check first') and names those alternatives. It stops short of stating when a caller should prefer this demo over other spend paths, but the sequencing guidance is concrete.

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 behavioral burden but only repeats that this is a GET request. It does not mention authentication, rate limits, response format, or any other operational characteristic.

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 short fragment with no wasted words and the endpoint is front-loaded. It is appropriately sized for a minimal GET operation, though it is arguably too sparse to be fully informative.

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 are no annotations, no output schema, and no parameters, the description should carry more context about what the trail resource contains and why an agent would call it. It only supplies an endpoint path, which is insufficient for confident selection among many siblings.

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 are no parameter semantics to explain. Per the scoring baseline for zero-parameter tools, this is 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 HTTP verb (GET) and resource path (/trail.json), making the basic retrieval action clear. However, it does not distinguish this tool from sibling GET endpoints or explain what the 'find-us trail' resource represents.

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 given about when to use this tool versus alternatives such as wall_get, llms_get, or showcase_get. The description offers only the endpoint path, leaving selection entirely 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?

With no annotations, the description carries the full burden and largely does: it discloses that GET avoids a refetch, that fresh checks are rate-limited, that local:true executes the bundled verify-ref.cjs on the caller's machine instead of Peerkith, and that ok:true only holds for the 'verified' tier. It stops short of describing auth requirements or the shape of the returned verdict.

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

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

Extremely dense and front-loaded — the two input→behavior mappings come first, then local execution, then the ok:true invariant. Nothing is padding, but the telegraphic brace syntax and slash-heavy sentences push it toward cryptic rather than clean.

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 6-parameter, 0-required tool with no output schema and no annotations, the description covers routing, one side-effect, and the ok:true invariant, but never sketches what a verdict response contains or how failures are surfaced. Adequate to invoke, incomplete to interpret.

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 only 17%, so the description must compensate, and it does: row is tied to the stored-verdict path, card+job+proof to the fresh-check path, and local to the reference-verifier path. 'fresh' semantics are covered by the schema itself. Minor gap: 'card', 'job' and 'proof' formats are never explained.

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 concrete verb (check/verify) mapped to two distinct input shapes, each with its own route (GET for stored verdict vs POST for fresh check). An agent can tell the two modes apart, though domain nouns like 'row', 'card', 'job' and 'Peerkith' are used without definition, and no sibling (e.g. cap_check) is named for contrast.

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?

Routing conditions are explicit: pass a row to get the stored verdict without refetch, pass {card, job, proof} for a fresh check, and proof alone yields ok:false with a stated reason. It also flags local:true as a substitute execution path. What's missing is guidance on when to prefer this over the capability siblings (cap_check, cap_preflight).

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. It discloses the important behavioral trait — default filtering to verified rows and the all:true escape hatch — plus the shape of returned rows (id, tier, verified_by). It says nothing about permissions, rate limits, or pagination, so it is adequate but incomplete.

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?

Very compact and front-loaded: default behavior first, override second, returned fields last. The telegraphic style is efficient for an agent, though the fragmented phrasing is slightly cryptic without surrounding context.

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 usefully enumerates the returned row fields (id, tier with its enum values, verified_by). Combined with the default-vs-all filtering rule, an agent has nearly everything needed to call and interpret this tool; only auth/permission context 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 coverage is 0% and the single parameter has no description, but the description compensates well: 'all:true = every row (?all=1)' explains both the semantic meaning and the wire encoding of the parameter.

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 ('GET wall'), names the underlying endpoint (/punch-list.json), and defines the default scope (verified rows only). It does not explicitly contrast itself with siblings like pending_get or trail_get, so it falls just short of 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?

Gives clear operational context: the tool defaults to verified-label rows and the caller opts into the full set via all:true. There is no statement of when to prefer a sibling tool or any exclusions, so it is context-rich but not fully routing-aware.

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