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?
Beyond the annotations, the description discloses that the row is deactivated rather than deleted, and that historical events remain available via recent_alerts. It also states ownership enforcement, which is a meaningful behavioral constraint not captured in 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?
Two concise sentences front-load the core action and are followed by a brief ownership note and a clarity about the deactivation behavior. Every sentence earns its place with no wasted words.
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 single-parameter mutation tool with no output schema, the description covers the essential context: what happens (cancellation/deactivation), the ownership constraint, and the impact on historical alerts. The annotations further cover safety and idempotency, making this complete.
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 fully documents the 'id' parameter, including its type and provenance ('returned by subscribe'). The description does not add additional parameter semantics beyond saying 'by id,' so it adds no extra value over the schema.
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 opens with a specific verb and resource: 'Cancel a subscription by id.' This clearly identifies the tool's action and scope, and it distinguishes from sibling tools like list_subscriptions and subscribe by focusing on cancellation.
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 usage context by noting ownership enforcement ('you can only cancel your own subscriptions') and the deactivation behavior. However, it does not explicitly state when to choose this over alternatives, leaving the 'when to use' somewhat implicit.
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 clearly distinct purposes with detailed usage guidance, but the several query entry points (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research) overlap conceptually and require careful reading to select correctly. Notably, ask_pipeworx_beta currently behaves identically to ask_pipeworx, which could cause confusion.
Tool names mix verb-first (remember, resolve_entity) and noun-first (entity_profile, deep_research) patterns, with some using prefixes like 'polymarket_' or 'ask_pipeworx'. While all are snake_case and readable, the lack of a single consistent convention makes the set feel less coherent than it could be.
33 tools is on the high end for a single server, though the broad domain (data retrieval, prediction markets, memory, subscriptions, web scraping) justifies much of the sprawl. Still, the count borders on heavy, and some tools could potentially be consolidated (e.g., the ask_pipeworx variants).
The toolset provides comprehensive coverage for its core data querying and analysis domain, with lifecycle coverage for memory and subscriptions. Minor gaps exist, such as no generic 'fetch page content' tool despite having get_metadata and take_screenshot, but these do not undermine the primary functionality.