get_member_by_id

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

No annotations are supplied, so the description carries the disclosure burden. It implies a read-only lookup and confirms the return shape, but never states that it is non-mutating, whether authentication/entitlement is required, or how the result behaves for an unknown ID. Adequate for a simple getter, but thin given zero annotation coverage.

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 and well-structured with Args/Returns blocks, but padded with a redundant synonym dump ('member details, MP profile, member information, parliamentary roles, constituency data') and the return summary is stated twice in nearly identical words. Roughly a third of the text does not earn its place.

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-parameter read tool with an output schema (so return values need not be enumerated), the description covers purpose, trigger condition, parameter sourcing, and sibling awareness. It is complete enough to call correctly; the only real gap is the absence of any explicit differentiation from the named sibling tools.

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 0% and the single parameter has no schema description, but the description compensates meaningfully: it marks member_id as required, tells the agent to obtain it from a member search first, and gives a concrete example value (1423). That is more than the schema provides and removes the main ambiguity about where the ID comes from.

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 names a specific verb+resource (retrieve a full member profile by ID) and lists the concrete data it covers: biographical, political, contact, roles, constituency, party, career. It explicitly names four sibling tools (get_mp_profile, get_members_biography, get_member_synopsis), so an agent can see alternatives exist, but it does not explain how this tool differs from them beyond 'comprehensive'.

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?

States a clear triggering condition: use when you have a member ID and need complete biographical, political and contact information. That is solid context, but there are no exclusions or explicit routing rules ('use X instead when you only need Y'), and the See-also list is bare names with no selection criteria.

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