get_mp_profile

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

No annotations are provided, so the description carries the full burden, and it does disclose the key behavioral trait: this is an aggregator that combines get_member_by_id, get_members_biography, search_roi, and get_member_voting into one response, plus what the response contains. It stops short of stating read-only/safety characteristics (implied by 'Get' but never asserted) or any cost/size caveats for the voting summary.

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?

The front-loaded purpose sentence, the usage line, and the Args/Returns blocks are efficient and well ordered, but the pipe-delimited keyword block ('complete MP info, full member profile, MP background, politician details, comprehensive member data') is redundant search-stuffing that adds no meaning and dilutes the useful content.

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 single-param aggregator with an output schema present, the description covers the essentials: what is combined, which tools feed it, the return contents, and how to source the ID. Minor gaps remain around whether the call is read-only and whether the voting activity payload is bounded or paginated.

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 0% for the single member_id parameter, so the description must compensate and does: it identifies it as the 'Parliament member ID', tells the agent to obtain it from member search first, and supplies a concrete example value (4514). That is more guidance than the bare integer-typed 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?

States a specific verb+resource ('Get comprehensive MP/Lord profile in one call') and enumerates the component data sets (member details, biography, interests, voting summary). It explicitly distinguishes itself from siblings by naming get_my_mp, get_member_by_name, and the four underlying tools it combines.

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?

'Use when you need a complete picture of an MP or Lord without multiple tool calls' gives the selecting condition, and 'See also' names the alternatives with their distinct roles (get_my_mp by postcode, get_member_by_name to find the member ID). An agent can route correctly without opening any other schema.

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