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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it constrains the search to tracked references rather than provider mailboxes and notes backward pagination for older results. It does not contradict the annotations.

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

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

At three sentences it is reasonably sized and front-loads the purpose, so the structure is sound. The first sentence is overloaded with jargon, and the trailing 'Pass nextCursor as before' sentence muddies rather than earns its place given the parameter mismatch.

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

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

For a read-only find tool with no output schema, the description covers scope and backwards pagination adequately. But it leaves return-format expectations and the semantics of the 'limit'/'before' parameters unaddressed, and the stray 'nextCursor' reference reduces completeness for correct invocation.

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

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

Schema description coverage is only 33% (only itemId is documented), so the description should compensate but does not. It references 'nextCursor', which is not a schema parameter at all (the schema has 'before'), introducing confusion rather than clarity while leaving 'limit' and 'before' unexplained.

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 (finding resource attachments and registered metadata) and scopes it to saved sender/thread associations for a project or task. It clarifies what is searched ('tracked references, not provider mailboxes'), which is genuinely useful. However, the dense jargon ('explicitly saved account-scoped sender/thread associations') makes the core purpose harder to parse than it needs to be, and no sibling tool (e.g., get_resources) is 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?

There is no explicit guidance on when to use this tool versus alternatives like get_resources, search_mentions, or resource_attach/detach. The only usage hint is the pagination note about older results, which is about mechanics rather than tool selection. An agent must infer the appropriate context.

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