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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does: every hit names its source page and original at the end of the answer, with an instruction to supply both links and cite by hit title. It also asserts a provenance guarantee (official-source original data only). It does not discuss result limits or ranking behavior.

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 resource and its metrics, then modes, then the citation requirement. Dense with parenthetical detail and multiple languages of jargon, but nearly every clause carries a distinct fact; a slightly tighter structure would improve scanability.

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?

There is no output schema, so the description must carry the return-shape burden, and it does by listing the metrics and the per-MEP profile fields (count, answered/open, typical response time, latest questions). Combined with the citation/source-link instruction, an agent has enough to invoke and present results; only result caps and empty-result behavior are unaddressed.

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 the baseline is 3, but the description genuinely adds meaning: it explains that year and country act as aggregation dimensions ('gesamt, je Jahr oder je Länderdelegation') and that mep_name switches the whole response to a different profile shape, which the schema alone does not convey. addressee and year semantics are largely left to the schema.

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?

Names a specific resource and scope: response times of the EU Commission (or Council) to MEP parliamentary questions, enumerating the exact metrics (median/mean/P90 in days, share within 6 weeks/3 months, open questions) and the aggregation levels (total, per year, per country delegation). It also explicitly distinguishes its two modes (aggregate vs. per-MEP profile via mep_name) and positions itself against get_ministry_responsiveness as the EU pendant.

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?

Clear context for both usage modes: default aggregation by year/country, or the per-MEP question profile when mep_name is supplied, plus the addressee switch COM vs. CONSIL. The reference to get_ministry_responsiveness implicitly routes national-ministry questions elsewhere. It stops short of explicit when-not-to-use or exclusion language.

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