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

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), it explains that name, contact and message are forwarded to the entry owner, that the owner replies directly to the user, and that there is a hard cap of one request per entry per day. Those delivery, privacy and rate-limit facts are exactly what the 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?

Three compact sentences, front-loaded with the action and the consent precondition, followed by delivery behavior and the rate limit. Every sentence carries a constraint an agent would otherwise get wrong.

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 write-side request tool with no output schema, it covers permission, recipient, delivery channel, rate limit and content rules. It does not say what a successful or rejected submission returns, which is a minor gap given there is no output schema to describe that.

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 83%, so the schema already documents most fields; the description still adds the origin of ding_id (from dinge_suchen) and reinforces the consent requirement, which is the highest-risk parameter. The optional phone parameter is not mentioned in the description, a small remaining gap.

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 concrete action and target: requesting contact with the person behind an entry, and it explicitly ties ding_id to dinge_suchen, which separates it from pure search tools. It does not distinguish itself from the sibling contact_provider, which also sounds like a contact/request flow, so an agent may still hesitate between the two.

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 gives a clear precondition ('Nur nach Zustimmung des Nutzers'), a rate limit ('Höchstens eine Anfrage je Eintrag und Tag') and a content restriction ('Keine Internet-Links'). What is missing is an explicit statement that the entry must first be found via dinge_suchen, and no explicit comparison with contact_provider.

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