memory_poisoning_scanner__scan_text

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

With no annotations, the description carries the full disclosure burden, and it does convey meaningful detection semantics (what counts as memory poisoning, including MemGPT archival/core memory and vector-store knowledge bases). However, it omits that this is a safe read-only operation, how findings are surfaced, or any limits on input size, so the behavioral picture is only partially filled in.

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 is a single dense sentence but it is front-loaded with the verb and risk class, and each clause (the two detection categories, the parenthetical memory-system examples) contributes real information. It is not padded, though the length is on the heavier side for a two-parameter 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 simple two-parameter scanner whose input schema is fully described, the definition adequately covers what is scanned but says nothing about the return shape. With no output schema present, the agent has no signal as to whether it receives findings, a severity list, or a pass/fail verdict, leaving a real 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?

Schema description coverage is 100%, so 'label' (optional filename for findings) and 'content' (the code to scan) are already documented in the schema. The description adds no additional parameter syntax or format detail, so the baseline of 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 pairs a specific verb ('Scan agent code') with a narrowly defined risk class ('memory-poisoning') and then enumerates the two concrete detection targets: unsanitized untrusted input written to persistent cross-session memory, and memory retrievals injected into system/assistant-role prompts. This is far more specific than a generic 'scan' tool and lets an agent distinguish it from the file/directory variants in the same family.

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 explains what the scan looks for but never states when to invoke this text variant versus scan_file, scan_directory, or list_patterns. There is no when-to-use, when-not-to-use, or alternative routing guidance, leaving the agent to infer usage purely from the name and parameter set.

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