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

Annotations already declare a safe read (readOnlyHint, idempotentHint, closed-world), and the description layers on real behavioral context not present in structured fields: the prompt is the same text edited under Clients → ⋮ → AI Instructions, only the prompt is returned regardless of on/off state, and the missing-tool case is a 404. These are precisely the extra traits this dimension rewards.

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?

Purpose and scope are front-loaded in the opening lines before the dashboard aside and error codes. Every sentence carries information, though the leading line duplicates the tool title and the dashboard-editing detail is slightly parenthetical.

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 one-parameter read-only getter with no output schema and annotations covering safety, the description supplies what the value is, its scope, availability, and the error case. The only omission is the response field shape, which is a minor gap given the tool's simplicity.

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 the single agent_id parameter already documents the uuid format plus the 404 agent_not_found and 403 agent_not_authorized cases. The description adds no new parameter meaning, so the baseline 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?

Specific verb+resource ('Get the lead capture prompt') followed by a precise scoping clause: it returns the instruction the built-in Capture Lead tool follows, not the tool's other settings. That boundary ('Only the prompt: the tool's other settings stay in the dashboard') cleanly separates it from the sibling update_lead_capture and from get_follow_up_settings.

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 states usable context clearly: the value is returned whether the tool is on or off, and an agent lacking the tool yields 404 lead_capture_not_found. It never explicitly says when to prefer this over get_agent or update_lead_capture, so it stops short of full when/when-not guidance.

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