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?
Adds meaningful behavioral details beyond the annotations: ownership enforcement, deactivation instead of deletion, and preservation of historical events via recent_alerts. This aligns with destructiveHint false and enriches the agent's understanding.
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, front-loaded with the action, and every clause adds value (ownership, deactivation, historical events). 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 simple one-parameter tool with rich annotations, the description covers the purpose, side effects, and data persistence behavior. The mention of recent_alerts provides integration context, and no output schema is needed.
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 complete coverage for the single parameter id, with a description ('returned by subscribe'). The tool description adds no further parameter detail, 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 uses a specific verb and resource ('Cancel a subscription by id') and distinguishes this tool from siblings like subscribe and list_subscriptions. It also clarifies that the row is deactivated rather than deleted, tying to 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?
Provides clear context: you cancel by id, ownership is enforced, and historical events remain available. It lacks explicit alternatives, but the scope is well-defined enough for an agent to know when to invoke 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.
The server contains 4 joke-related tools and 31 tools from the Pipeworx data ecosystem, which are entirely unrelated. An agent cannot easily distinguish whether to use a joke tool or a data tool, causing extreme ambiguity.
Tool names within the joke subset (e.g., get_joke, search_jokes) and Pipeworx subset (e.g., ask_pipeworx, entity_profile) are individually consistent, but the overall set has no unified naming pattern or domain signal, making the server's purpose unclear.
With 35 tools, the count is excessive for a jokes-themed server. Only 4 tools are joke-related; the remaining 31 belong to a completely different domain, making the tool count highly inappropriate.
The joke coverage (get, search, categories, flags) is minimal but functional. However, the server as a whole is a Frankenstein of unrelated domains, lacking a coherent surface. The overwhelming majority of tools are irrelevant to the server name.