get

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does disclose a key behavior: the response includes a top-level 'metadata' object with a 'secret: true' flag that can be intercepted for sanitization or secure handle-based access. This is valuable, non-obvious behavior worth flagging. It does not mention auth requirements or other edge behaviors, but the disclosed secret-handling mechanism is significant and well beyond what an agent would guess.

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 appropriately concise at two sentences, front-loaded with the core purpose ('Get a specific field for an item'). The second sentence about the metadata 'secret' flag earns its place by disclosing relevant behavioral context. No wasted words or redundant content.

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

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

For a simple two-parameter tool with full schema coverage and no output schema, the description adequately covers the essentials: core purpose, default field behavior, recommended workflow (list first), and notable response metadata. It doesn't describe return value structure, but for a simple retrieval tool, this is mostly inferable, and no output schema exists to add more. The missing piece is mild — how the password is returned (raw vs. wrapped).

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 input schema already fully documents both parameters (id and field). The description adds the default-value insight that 'field' defaults to the item's password, which is useful beyond the schema. However, most parameter meaning comes from the schema itself, so the description's incremental value is modest but real.

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 retrieves a specific field for an item (defaulting to password), with a specific verb ('Get') and resource ('item field'). It doesn't explicitly distinguish from sibling tools like 'list', though the purpose is clear enough that an agent could reasonably infer the difference. A slightly more explicit sibling distinction would merit 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?

It explicitly recommends using 'list' first to find the exact item ID, giving clear sequencing guidance that helps an agent understand the tool's position in a workflow. It does not, however, describe when to prefer this over other tools or exclusion criteria, but the 'use list first' recommendation provides solid practical context.

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