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?
Beyond the readOnly/idempotent annotations, the description discloses the exact return fields (id, type, params, created_at, last_fired_at, fire_count) and caller-specific scoping. It does not mention pagination, but the tool is simple enough that this is acceptable.
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?
Three sentences: purpose, return fields, and usage guidance. Every sentence adds distinct value with no redundancy, filler, or fluff.
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 description covers purpose, return values, and when to use the tool. Combined with annotations that declare it safe and idempotent, it is fully complete for this simple read-only operation. No output schema is necessary because return fields are explicitly listed.
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 schema already provides 100% coverage for the single parameter 'include_inactive' with a clear description. The tool description adds the context of 'active' but does not elaborate on the parameter itself, warranting the baseline score 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 precisely states 'List the caller's active subscriptions' with a clear verb, resource, and scope. It distinguishes itself from sibling tools by mentioning 'before adding more' (subscribe) and 'to find an id to cancel' (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?
It provides explicit use cases: 'review what you're monitoring before adding more' and 'find an id to cancel.' However, it does not name sibling tools as alternatives directly, so it falls slightly short of a 5.
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 set contains multiple near-identical query tools (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research) and five overlapping prediction-market tools (polymarket_arbitrage, polymarket_edges, polymarket_edge_tracker, polymarket_fill_risk, polymarket_kalshi_spread) that an agent could easily confuse. The Studio Ghibli tools are clear enough, but they are drowned out by a large unrelated cluster with fuzzy boundaries.
There are small internally consistent clusters (polymarket_* tools, ask_pipeworx variants, singular/plural Ghibli resource pairs), but the overall set mixes simple nouns (film, person, location), imperative verbs (remember, forget, recall), and descriptive compound names (ai_visibility_check, generate_llms_txt, scan_competitor_ai_presence). The species tool is 'species'/'species_one' while every other resource uses bare singular for the single-item fetch, breaking the otherwise predictable Ghibli pattern.
A server named 'Studio Ghibli' exposes 41 tools, but only 10 of them relate to Ghibli content; the other 31 are an unrelated general-purpose data, prediction-market, memory, and subscription toolkit. This is an extreme mismatch between the apparent purpose and the actual tool surface.
For the Ghibli data domain itself, the surface is solid: films, people, locations, vehicles, and species all have list and single-item lookup, plus cross-links between entities. Minor gaps exist, such as no search or filter capability and no way to fetch films by director or year, but the core read-only catalog is well covered.