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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds transparency by listing the exact return fields (id, type, params, etc.) and the purpose, which is sufficient for a simple list operation.
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 concise with two sentences. The first sentence states the action and return format, and the second provides usage context. No unnecessary words or redundancy.
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?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the essential aspects: purpose, return fields, and usage. It does not explain what subscriptions are, but that is likely implied. Overall, it is complete enough for effective use.
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 coverage is 100% with the single parameter 'include_inactive' already described in the schema. The description does not add any additional meaning or usage guidance for this parameter, so it meets the baseline of 3.
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 that the tool lists the caller's active subscriptions and enumerates the specific return fields (id, type, params, etc.). It is easily distinguishable from sibling tools like subscribe and unsubscribe, which are different operations.
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 provides explicit usage guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This gives clear context for when to invoke the tool, though it does not explicitly state when not to use it or mention 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.
Several tools have heavily overlapping entry points: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, and validate_claim all take natural-language factual questions, and ask_pipeworx_beta is explicitly identical to ask_pipeworx right now. There is also overlap among get_states, get_aircraft, and airspace_activity, plus a large cluster of prediction-market tools with similar discovery purposes.
The set is mostly snake_case and readable, with familiar patterns like get_*, list_*, resolve_*, and compare_*. It is not chaotic, but there are notable deviations: noun-phrase names like entity_profile, recent_changes, ai_visibility_check, and airspace_activity break the verb-first pattern.
35 tools is too many for a single coherent server, especially because they comprise several independent families: aviation, data/research, prediction markets, memory, and subscriptions. Each tool is individually justified, but the bundle should be split into smaller focused MCP servers.
The data-research side is fairly complete, with discover, routing, grounded verification, entity resolution, search-within, compare, and follow-up tools, and the subscription and memory lifecycles are covered. However, the OpenSky side is incomplete: get_flights explicitly cannot return its data, and referenced route/arrival/departure tools are missing from the set.