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 readOnlyHint, idempotentHint, and non-destructive. The description adds that the response is scoped to the caller's subscriptions, defaults to active only, and lists the exact fields returned. This goes beyond the annotations and explains what the agent can expect.
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 with no redundancy. The first sentence states purpose and output, the second gives usage guidance. Well front-loaded.
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?
The tool is simple with one optional parameter and rich annotations. The description provides return fields which substitutes for an output schema, and gives context for use with subscription management. Complete for this level of complexity.
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 only parameter include_inactive is fully described in the schema with 100% coverage, including default behavior. The description does not mention the parameter, so no additional semantics are added.
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 it lists the caller's active subscriptions, specifying the resource and scope. Distinguishes from sibling subscribe/unsubscribe by being the read-only listing tool. Also enumerates return fields.
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?
Explicitly states to use this to review existing subscriptions before adding more or to find an id to cancel. This directly ties to sibling subscribe/unsubscribe actions, though it doesn't name them. Provides clear context for when this tool is appropriate.
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.
Several tools occupy overlapping question-answering territory: ask_pipeworx_beta currently behaves identically to ask_pipeworx, while ask_pipeworx_grounded, deep_research, and validate_claim all route the same data catalog and differ mainly in output guarantees. The six Polymarket tools also split edge detection, arbitrage, and fill-risk in ways that are easy for an agent to conflate. Clear exceptions like the memory and subscription trios keep it from a 1.
Names are uniformly lowercase snake_case and most follow a readable verb-first or domain-prefixed pattern (get_package, list_releases, scan_dependency, ask_pipeworx_*). The Polymarket family uses noun phrases after a prefix (polymarket_edges, polymarket_fill_risk) and a few names are noun-first (entity_profile, recent_changes), which is a minor inconsistency rather than chaos.
35 tools is well beyond the comfortable 3-15 range and even above the 16-25 heavy range. The broad Pipeworx data scope justifies some expansion, but identical ask_pipeworx_beta, six overlapping Polymarket tools, and unrelated utility families (Hex.pm, AI visibility, memory, llms.txt) suggest bloat rather than deliberate scoping.
Within its main data-access purpose, the surface is unusually complete: query (ask_pipeworx), grounded verification (ask_pipeworx_grounded/validate_claim), deep research, entity resolution/profiling, comparison, change feeds, and search-within are all present, and memory/subscription subdomains have full CRUD. There are minor gaps for the package side (no docs/dependents) and the hodgepodge of domains makes a single 'complete' surface hard to define, but no workflow hits a hard dead end.