guardAgentMemory

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description does add genuine non-annotation context: the operation costs 0.02 USDC on Base and is framed as a mandatory gate. It does not describe latency, failure behavior, or what the 'verified safety metrics' actually contain, so it is adequate but not rich.

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 repeats itself: it states the tool scans RAG chunks and memory payloads for sleeper injections twice, and the middle 'Usage' sentence is off-topic for a memory-scanning tool. Front-loading the mandatory-gate framing is fine, but the redundancy and the misaligned usage sentence waste the space.

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 the return value, yet 'Returns verified safety metrics' is left entirely vague for a security gate whose output determines whether a chunk is persisted. Combined with usage guidance that points at unrelated crypto-audit tasks, an agent cannot confidently determine how to act on the result.

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 documented in the schema, so the schema carries the load. The description only loosely restates that memory/RAG chunks are scanned and never explains the role of session_id, adding no meaning beyond the schema. Baseline 3 is appropriate.

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

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

The first sentence gives a specific verb and resource: scanning RAG chunks and agent memory payloads for sleeper-agent instructions and cross-session poisoning. However, the purpose is muddled by a usage sentence that redirects the tool toward smart-contract audits, wallet analysis, and DEX liquidity on Base/Solana, which has nothing to do with memory scanning. The core purpose is stated but undercut by this contradiction.

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?

A 'Usage' clause is present, so there is some routing guidance, but it names the wrong tasks entirely: auditing smart contracts, analyzing wallet addresses, and validating DEX liquidity. None of these relate to scanning memory/RAG chunks for prompt injections, so the guidance actively misroutes the agent rather than helping it choose this tool over siblings like auditMcpToolPoisoning or canary_sanitize.

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