seller_disclosure_usUNITED STATES. Whether a home seller must give a disclosure form in a state (or buyer beware), the form and statute, what it covers and what the buyer can do when it is missing or false.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | US state: any of the 50 states, by name or two-letter code (e.g. "Texas", "TX"). |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds value by disclosing the scope of the returned subject matter (form, statute, coverage, remedies for missing/false disclosure), which partly stands in for the absent output schema.
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?
A single sentence with no filler, front-loaded by jurisdiction, and the rest of the sentence is a compact enumeration of the tool's outputs. Every clause carries information.
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 lookup with no output schema, the description covers the input domain (a US state) and the answer's dimensions (requirement, form/statute, coverage, remedies). Nothing an agent needs to call and interpret it is missing.
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 'state' parameter is fully documented in the schema, including the name/two-letter-code format. The description only echoes the state scoping ('in a state') without adding any format or validation detail, so 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?
The description names the specific subject (US state seller disclosure law) and enumerates exactly what the tool returns: whether a form is required or it's buyer-beware, the form and statute, its coverage, and buyer remedies. It is clearly distinguishable from price/tax/closing siblings, though it never names an alternative tool explicitly.
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?
Usage is implied by the 'UNITED STATES' scope prefix and the state-level framing, so an agent can infer this is the state-disclosure reference for US transactions. However, there is no explicit when-to-use guidance and no routing away from adjacent tools like state_overview_us or federal_guide_us.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.