list_subscriptionsList the caller's active subscriptions. Returns id, type, params, created_at, last_fired_at, fire_count for each. Use this to review what you're monitoring before adding more or to find an id to cancel.
| Name | Required | Description | Default |
|---|---|---|---|
| include_inactive | No | Include cancelled subscriptions in the response (default false). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description adds value by listing the exact return fields and the active-only default. This gives the agent a clear picture of the response shape without needing an output schema.
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 sentences, no redundant phrasing. The first sentence states the action and return fields; the second sentence gives practical guidance, earning 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?
Low complexity tool with one optional parameter and no output schema. The description adequately specifies return fields and typical use cases, making it self-contained for invocation.
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 covers 100% of the single parameter with its own description. The tool description does not add additional semantics beyond the schema's include_inactive explanation, so baseline 3 is appropriate.
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?
Clearly states the tool lists the caller's active subscriptions with a specific verb and resource. It doesn't explicitly distinguish from sibling tools, but the resource scope is unambiguous and distinct from subscribe/unsubscribe.
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?
Provides explicit usage context: review before adding more subscriptions and find an id to cancel. No exclusions or alternatives mentioned, but the context is clear for when to invoke this tool.
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.
The descriptions are extraordinarily detailed and do a lot of work to differentiate tools, but there is real functional overlap: three ask_pipeworx variants, six Polymarket/bet tools (bet_research, polymarket_edges, polymarket_edge_tracker, polymarket_arbitrage, polymarket_fill_risk, polymarket_kalshi_spread) that all target identifying betting/value opportunities, and overlapping ai_visibility_check vs scan_competitor_ai_presence. A capable agent could navigate it, but misselection risk is high.
Mostly snake_case and readable, but the verb/noun placement is inconsistent: verb-first (get_makes, list_subscriptions, resolve_entity, decode_vin) mixes with noun-first (entity_profile, bet_research, pipeworx_trending) and branded prefixes (ask_pipeworx, pipeworx_feedback, polymarket_*). No chaotic camelCase mixing, but no single predictable pattern either.
37 tools is well beyond the heavy threshold, and the server named 'Nhtsa' carries only ~6 vehicle-specific tools while the rest is a general-purpose research platform spanning prediction markets, memory, npm packages, AI-marketing audits, and subscriptions. The scope is overloaded and the name badly misrepresents the content, making the surface feel sprawling rather than focused.
For the NHTSA vehicle domain it covers the lookup surface well (makes, models, recalls, complaints, safety ratings, VIN decode), and the broader research platform is genuinely deep with grounding, grounding-with-evidence, discovery, subscription, and memory support. Minor gaps exist (no direct vehicle-make year filtering beyond three fields, USPTO patent APIs are soft-failing), but no dead ends for core workflows.