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

Annotations are all false, so the description carries the burden of disclosing behavior. It adds context: the tool records a question, requires notifying the user, and enforces a privacy constraint on the description field. This goes beyond what annotations convey, providing meaningful operational details.

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 front-loaded with purpose, then usage, then privacy, then category list. It's efficient with no redundancy, though the category list could be considered slightly repetitive with the schema's default, but it adds the enum values not present in the schema. Structure is clear and scannable.

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 logging tool with no output schema, the description covers the essential aspects: purpose, when to use, parameter semantics, and privacy. It doesn't discuss return values or errors, but these are likely trivial for this tool. The distinctiveness from siblings is established, making it complete enough 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 0%, so the description must explain both parameters. It does: the `description` parameter is defined as the capability needed, with a privacy rule, and the `category` parameter lists its valid values (rental_metrics, str_airbnb, valuation, move_vs_stay, data_coverage, other). This fully compensates for the missing schema descriptions.

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 verb 'Record a question' and the resource 'TerraVue could not answer', defining its exact purpose. It explicitly distinguishes from sibling analysis tools by framing it as a logging tool for unmet requests, making its role 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?

The description provides explicit 'when to use' guidance: 'Call this whenever a user asks for something outside the current tools' coverage', listing concrete examples. It also instructs the agent to tell the user the request was captured. It doesn't state exclusions or alternatives, but the context implies siblings handle covered cases, so guidance is clear and actionable.

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