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

Annotations already declare read-only/idempotent/non-destructive, and the description adds cost and limit semantics that annotations cannot express: no data credit charges, uncached reads count toward the API request limit, and identical requests are cached for 15 minutes. It also discloses pagination behavior (omitting search returns all pages), which materially affects invocation.

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?

Four sentences, front-loaded with what is returned, then filtering behavior, then cost/limit implications, then caching. Every sentence carries information an agent needs; no filler or restatement of the title.

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?

With no output schema, the description correctly covers the return shape (field ID, source type, data type, description) and pagination behavior. For a zero-required-parameter read-only listing tool, this is complete enough to invoke confidently without further exploration.

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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: 'search' is a fuzzy concept match across field metadata rather than an exact filter, and omitting it changes scope from filtered to all pages. It does not elaborate on group_id or source_type semantics, keeping it just short of a 5.

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?

States a specific verb and resource ('Returns available DealMachine data fields') and enumerates the returned attributes (field ID, source type, data type, description). This is clearly a metadata/schema-discovery tool, distinguishable from sibling search tools like dealmachine_property_search or dealmachine_people_search that consume these fields.

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?

Gives clear context: use it to obtain field definitions, and 'Reuse these definitions for subsequent lookups' tells the agent to consult this before other calls. It does not explicitly name which siblings consume these fields or when to prefer a different discovery endpoint, so it falls short of full when/when-not routing.

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