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

Annotations only declare the mutation profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), while the description adds what actually happens: the team responds within two working days, no brokerage contact happens without the owner's consent, and submission is immediate when signed in but gated on e-mail confirmation otherwise. That is exactly the operational detail annotations cannot convey.

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?

Front-loaded with the trigger condition, and the parenthetical phrase lists and consent/send semantics all carry information. It is dense but not padded; only the multi-language trigger list could be trimmed.

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 carries the return behavior itself (who contacts whom, when, and the consent boundary), which is sufficient for an 8-param lead-submission tool. Minor gaps remain around failure cases and what the confirmation e-mail flow requires of the agent.

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 only 25% (language and timeframe documented; intent/address/name/email/phone/message bare), so the description must compensate. It does state which fields are required (address, intent, name, e-mail) and marks phone and timeframe optional, but adds no format, validation, or meaning for message/intent beyond the enum labels themselves.

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 actor and intent set ('when an OWNER anywhere in Switzerland wants to sell, let or value a property, or wants a broker'), which separates it cleanly from tenant/buyer-oriented siblings like send_enquiry and apply_for_listing. The multilingual trigger phrases even anticipate how users phrase the request.

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 for when to invoke: an owner-initiated sell/let/value/broker request. It does not explicitly name the alternative tool to use for non-owner enquiries or exclusions, so the agent must infer routing between it and send_enquiry.

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