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 establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by specifying the caller scope and the exact return fields, which is valuable since no output schema exists. It does not contradict any annotation.
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?
The description is two sentences with no fluff. It front-loads the purpose, then lists return fields, then provides usage guidance. Every sentence earns 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?
For a simple list tool with one optional parameter and no output schema, the description is complete. It covers purpose, return fields, caller scoping, and practical use cases. No significant gaps.
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 optional parameter include_inactive. The description mentions 'active subscriptions' which implies the default, but adds no new semantics beyond the schema. Baseline of 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?
The description clearly states the verb and resource: 'List the caller's active subscriptions.' It also lists the returned fields (id, type, params, etc.), making the tool's functionality concrete and distinguishing it from subscribe/unsubscribe siblings.
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 explicitly provides usage context: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This directly ties to the sibling tools subscribe and unsubscribe, offering clear when-to-use guidance without restating alternatives.
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 toolset contains several heavily overlapping families: ask_pipeworx, ask_pipeworx_beta, and ask_pipeworx_grounded are near-duplicates (beta is currently identical), and polymarket_edges, polymarket_arbitrage, and bet_research cover adjacent purposes. Even though descriptions are detailed and attempt to differentiate, an agent can easily route a query to the wrong member of a cluster.
Most names are readable snake_case, but the set does not follow a single convention: it mixes verb-first names (get_flood_forecast, subscribe), noun-phrase names (entity_profile, recent_changes, pipeworx_feedback), and product-prefixed families (polymarket_*). The verb style is also inconsistent across ask, get, list, scan, validate, generate, and discover, so names don't reliably predict what a tool does.
33 tools is well above the 25-tool boundary for a coherent set, and the server's nominal 'flood' scope accounts for only two of them. The rest belong to unrelated domains like general data lookup, prediction markets, memory, and subscriptions, making the set feel like several MCP servers merged together.
For the broad data-agent scope, coverage is fairly strong: querying, entity resolution, memory lifecycle, subscription lifecycle, and prediction-market analysis all have their major operations represented. However, the flood domain implied by the server name is thin—only forecast and river discharge, with no historical series, flood-specific alerting, or location-focused risk tools—so the surface is not clearly complete for any single stated purpose.