list_issue_codesList the valid general issue area codes used by LDA filings (the values accepted by the issue filter on search_filings), e.g. TAX=Taxation, HCR=Health Issues, ENV=Environment. Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, covering safety. The description adds that the tool is 'Keyless' (no params) and provides example outputs, which is helpful but not critical beyond annotations.
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 concise sentences. The first sentence states the purpose and connection to search_filings. The second adds examples and 'Keyless'. No extraneous text.
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 zero-parameter tool with no output schema, the description is complete. It explains what is listed, provides examples, and notes the relationship to search_filings. No additional information needed.
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?
There are zero parameters. The description notes 'Keyless', which suffices. Baseline 4 for no parameters.
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 lists valid LDA issue area codes, provides examples (TAX, HCR, ENV), and connects to the `issue` filter on search_filings. The verb 'list' and resource 'issue codes' are specific and unambiguous.
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 implies usage: when you need valid values for the `issue` filter in search_filings. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an AI agent.
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.
There are several near-duplicate clusters: ask_pipeworx, ask_pipeworx_beta (explicitly described as currently identical), ask_pipeworx_grounded, deep_research, and validate_claim all route to the same underlying data; the six Polymarket tools (bet_research, arbitrage, edges, edge_tracker, fill_risk, kalshi_spread) heavily overlap in purpose and are easy to confuse. Even detailed descriptions do not fully resolve which tool an agent should pick first.
All names use snake_case and many follow a verb_noun pattern (search_filings, get_filing, list_issue_codes, resolve_entity), but there is a mix of verb-first names (ask_pipeworx, compare_entities, generate_llms_txt), noun-first names (recent_changes, entity_profile, pipeworx_trending), and brand-prefixed families (pipeworx_*, polymarket_*). The naming is readable but not a single predictable pattern.
A server named 'Senate Lobbying' exposes 34 tools, but only three (search_filings, get_filing, list_issue_codes) relate to LDA lobbying data. The remaining 31 cover generic Pipeworx data lookup, prediction markets, memory, subscriptions, AI visibility, and npm package audits—an extreme overreach for the apparent scope and likely to confuse an agent expecting a focused lobbying toolkit.
For the lobbying domain implied by the server name, only search, get-one-filing, and issue-code enumeration exist; there is no aggregation/stats tool, no lobbyist/client entity resolution for LDA, no registrant or foreign-entity browsing, and no coverage of related concepts like lobbying firm hierarchies or spending trends. The generic Pipeworx tools fill a different domain, so the lobbying-specific surface has significant gaps.