Examine the legislative floor of the UAW: proposals for constitutional amendments, policy changes, and new worker protections currently under deliberation. Filter by status to track what is open for debate, under vote, or already decided.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by proposal status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It conveys that this is a read-oriented examination tool and mentions the status values (open, under vote, decided), but does not disclose return format, pagination, or any explicit read-only guarantee. This is adequate but not richly transparent.
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?
Two engaging sentences with a clear verb and resource upfront. The metaphor 'legislative floor' is immediately explained, and every clause contributes either to purpose or parameter semantics. No filler.
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 simple list/filter tool with one optional parameter and no output schema, the description covers the core purpose and the status filter effectively. It does not explain the return format or default behavior when no filter is applied, but this is a minor gap given the tool's simplicity.
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?
The input schema has 100% coverage for the single 'status' parameter, but the description adds valuable meaning by enumerating the semantic categories (open for debate, under vote, already decided), which go beyond the generic schema description 'Filter by proposal status'.
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 clearly states the tool examines legislative proposals in the UAW, listing specific content types (constitutional amendments, policy changes, worker protections) and includes a filterable status dimension. This distinguishes it from siblings like get_resolutions or get_feed by focusing on the deliberative proposal lifecycle.
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?
The description explains the tool's context (legislative floor) and explicitly instructs how to use the status filter to track proposals at different stages. It does not name alternative tools or state when not to use it, but the usage context is clear enough for most cases.
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.
Each tool targets a distinct resource or action: proposals, grievances, members, stats, feed, and resolutions are clearly separated. Even similar getters (get_member vs get_members) are unambiguous, and governance actions like create, deliberate, file, vote, support, and open vote have specific scopes with no overlapping purposes.
Tool names follow a consistent snake_case verb_noun pattern (e.g., get_proposals, create_proposal, vote_on_proposal). The only deviation is 'my_vote', which is a noun phrase rather than a verb command, but this is minor and does not create confusion.
At 17 tools, the set is slightly above the typical 3-15 well-scoped range, but the domain is broad (membership, proposals, grievances, platform overview). Each tool serves a distinct purpose and none feel redundant, so the count is justified.
The core lifecycle is well covered: joining and profile updates, proposal creation/deliberation/voting, grievance filing/support/classification, and governance overview via feed, stats, and resolutions. Minor gaps exist, such as no way to edit a proposal or view detailed voting tallies, but these are workable.
