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

With no annotations, the description carries the behavioral disclosure burden. It usefully states that the request is submitted by the person, not on their behalf, preventing the agent from assuming the tool performs the submission. It does not mention potential side effects or external navigation, but for a simple return-link tool this is sufficient.

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 front-loads the purpose and immediately states the key behavioral caveat ('not on their behalf'). Every part of the description earns its place, with no unnecessary verbosity.

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?

The description identifies both return values—the form link and GDPR consent text—and clarifies that the user submits the request. For a one-parameter tool with no output schema, this covers the essential information. Only minor details such as how to present the consent text are 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?

The input schema already documents the language parameter, supported values, and default with 100% coverage, so the baseline is 3. The description adds the 'in the user's language' context but no substantive new parameter semantics beyond what the schema provides.

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 states a specific verb and resource: putting the user in touch with a licensed real estate agency in Portugal. It also names concrete outputs—the form link and GDPR consent text—which clearly distinguishes it from the sibling tax/fee calculation tools.

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 gives no explicit guidance on when to use this tool versus alternatives, nor does it mention sibling tools or exclusion conditions. An agent must infer from the sibling names that this is the consultation option, but the description itself does not provide selection criteria.

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