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 this as safe, read-only, and idempotent. The description adds useful behavioral context: it only returns the caller's own subscriptions, lists the exact fields returned, and implies that inactive subscriptions are excluded by default via the mention of 'active'. This exceeds the annotation baseline without overpromising.
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: the first states purpose and return fields, the second gives concrete use cases. No filler, front-loaded, and 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 fully covers what is returned, the default scope, and the primary use cases. No critical gaps remain.
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 include_inactive parameter is well-described in the schema itself. The description adds minimal parameter context beyond calling subscriptions 'active', so it doesn't need to compensate. 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 the tool lists the caller's active subscriptions, with a specific verb and resource. It also enumerates the returned fields, making the purpose concrete and distinguishable from sibling tools like 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?
The description explicitly advises using this tool to review current monitoring before adding more subscriptions or to find an id to cancel. It implies when to use it relative to subscribe/unsubscribe, though it doesn't name those alternative tools explicitly or state when not to use it.
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 are carefully delineated with explicit use-case guidance; ask_pipeworx, ask_pipeworx_grounded, and deep_research are clearly separated by depth and grounding. The main weak spots are ask_pipeworx_beta, which is a current functional duplicate of ask_pipeworx, and the several prediction-market/company-research tools that still require careful reading to pick correctly.
Names are uniformly snake_case and mostly command-like, with coherent families such as polymarket_*, ask_pipeworx_*, get_art*, subscribe/unsubscribe, and remember/recall/forget. The pattern is not strictly verb_noun throughout, since noun phrases like entity_profile, pipeworx_trending, and recent_changes appear, but the inconsistency is minor and readable.
35 tools is well past the 25+ threshold for a single MCP server, and the set bundles Art Institute lookups, Pipeworx data research, prediction-market analysis, memory, subscriptions, and website utilities into one place. Many tools earn their keep individually, but the overall toolbox feels bloated and poorly scoped.
The Pipeworx, memory, and subscription subgroups have decent lifecycle coverage: remember/recall/forget and subscribe/unsubscribe/listsubscriptions/recent_alerts form coherent loops. But relative to the 'artic' server name, the Art Institute surface is thin—there is no artist search and no exhibition-detail tool—and the unrelated embedded domains prevent the set from feeling complete for any one clear purpose.