unsubscribeCancel a subscription by id. Ownership is enforced — you can only cancel your own subscriptions. The row is deactivated (not deleted) so its historical events stay available via recent_alerts.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Subscription id (uuid) returned by subscribe. |
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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context: ownership enforcement (can only cancel own subscriptions) and that the row is deactivated (not deleted) so historical events remain available. This clarifies the exact side effects beyond what annotations provide.
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: three sentences that are front-loaded with the core action ('Cancel a subscription by id'), followed by essential behavioral details. Every sentence adds value without 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 has only one parameter, no output schema, and annotations cover safety and idempotency, the description is sufficiently complete. It explains the effect (deactivation not deletion), ownership, and the relationship to 'recent_alerts'. No further information is needed for an agent to use this tool correctly.
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 with a description for the 'id' parameter: 'Subscription id (uuid) returned by subscribe.' The tool description does not add any additional parameter details beyond the schema, so the baseline score of 3 applies.
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 'Cancel a subscription by id', specifying the verb and resource. It distinguishes from siblings like 'subscribe' and 'list_subscriptions' by noting ownership enforcement and that the row is deactivated, not deleted, keeping historical events available via 'recent_alerts'.
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 indicates when to use the tool (to cancel a subscription) and provides context such as ownership enforcement and that the action is a deactivation, not deletion. It does not explicitly state when not to use it or compare to alternatives like permanent deletion, but the sibling context and behavior hints are sufficient.
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.
Multiple tool clusters have overlapping purposes: ask_pipeworx, ask_pipeworx_beta, and ask_pipeworx_grounded are near-identical (the beta is explicitly the same right now); five polymarket_* tools all surface opportunity/edge information; entity_profile, compare_entities, and recent_changes all cover company research. The descriptions are detailed, but an agent can easily misselect between similar tools.
All tool names use consistent snake_case and are descriptive, with clear prefix patterns for prediction-market tools (polymarket_*) and the router variants (ask_pipeworx_*). Some names are verb-noun while others are noun-phrases, but the convention is uniformly underscore-separated, with no camelCase or other mixing.
33 tools is excessive for a coherent server, and the scope is sprawled across EMDB access, Pipeworx data routing, prediction markets, memory, subscriptions, and miscellaneous utilities. Even though each tool has a defined role, the sheer breadth and number make it feel like several servers' worth of functionality crammed into one.
The server's name suggests it should be focused on EMDB, but only two tools (get_map, search_maps) cover that domain — no browsing, filtering, or extended metadata beyond basic fields. Meanwhile, the bulk of the surface is devoted to unrelated Pipeworx/platform features. For the stated purpose, the coverage is severely incomplete.