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=true and destructiveHint=false, so the safety profile is clear. The description adds the list of returned fields, which supplements behavioral understanding without contradicting 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?
The description is two sentences, front-loading the core action and followed by usage guidance. Every sentence adds value without fluff, making it highly efficient.
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, strong annotations, and no output schema, the description covers purpose, output fields, and usage scenario completely.
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% and the description for the only parameter ('include_inactive') exactly matches the schema description. The description adds no new meaning beyond what the schema already provides, 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?
The description clearly states it lists the caller's active subscriptions, specifying returned fields. While the purpose is clear, it does not explicitly differentiate from sibling tools like subscribe or unsubscribe, but the verb and resource are distinct enough.
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 guidance on when to use the tool: to review subscriptions before adding more or to find an id to cancel. It doesn't mention when not to use or alternatives, but the given context is helpful.
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.
Most tools have detailed descriptions that clearly delineate their purposes, but ask_pipeworx_beta is currently functionally identical to ask_pipeworx, and deep_research overlaps with ask_pipeworx for multi-part questions. The six polymarket_* tools also share related territory, though their boundaries are well-documented.
All names use snake_case, and domain prefixes like polymarket_, pipeworx_, and ask_ add predictability. However, the set mixes verb-led names (compare_entities, resolve_entity, search_within) with noun-led names (entity_profile, recent_changes, bet_research), so there is no single consistent verb_noun convention.
35 tools is well above the 15-25 'heavy' band and feels like a kitchen sink: the server bundles a data-research platform, prediction-market analysis, memory, subscriptions, number conversions, and web-dev utilities into one surface. Many of these are unrelated to the server's 'Numbers' identity.
The main subdomains are thoroughly covered: data lookup (ask_pipeworx variants, deep_research, validate_claim), prediction-market analysis (arbitrage, edges, fill risk, kalshi spread), memory (remember/recall/forget), and subscriptions (subscribe/list/unsubscribe/recent_alerts). Minor gaps exist, such as no subscription update operation, but core lifecycle coverage is strong.