Roll-call votes of one member with title, date and whether against the party line.
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"member": "<member>"
},
"name": "get_member_votes"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| member | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the returned fields, but says nothing about permissions, pagination, result ordering or volume for what is typically a long historical roll-call record, and the read-only safety profile is only implied by the 'get_' prefix.
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?
One tight sentence with no filler, and the subject of the lookup is front-loaded. Nothing padding is present, though the sentence is a fragment without a verb, which slightly weakens readability.
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?
With no output schema and no annotations, the description must carry everything. It does cover the shape of the returned row (title, date, party-line flag), which is genuinely useful, but leaves the member identifier format, pagination and result volume 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 description coverage is 0% and the single 'member' parameter is completely undocumented. The phrase 'of one member' confirms the parameter identifies a member, but gives no format guidance (ID vs name vs slug), which is the exact ambiguity an agent would need resolved.
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 gives a specific verb+resource (roll-call votes of one member) and even names the payload fields (title, date, party-line deviation), which separates it from the fleet-wide list_roll_call_votes and from get_member. It stops short of explicitly naming those siblings, so it is clear but not fully self-differentiating.
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?
There is no when-to-use guidance, no mention of list_roll_call_votes as the alternative for all members, and no stated preconditions. The only hint of usage is the phrase 'of one member', which the agent must infer means 'use only when you have a single member in hand'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.