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 key behavior beyond annotations: deactivation rather than deletion, and the impact on recent_alerts. The annotation already marks non-destructive and idempotent, but description enriches with consequences.
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 crisp sentences, action-first, with no filler. Each sentence adds essential information (ownership, deactivation effect).
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, the description covers purpose, constraint, and side-effect. Combined with thorough schema and annotations, it's complete and well-contextualized.
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 fully documents the only parameter id, including its source ('returned by subscribe'). Description adds no further parameter detail, matching the baseline for high schema coverage.
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?
States 'Cancel a subscription by id' with a specific verb and resource. The ownership and deactivation details clarify scope, distinguishing it from subscribe/list_subscriptions.
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?
Implies usage context as the cancellation counterpart to subscribe, and notes the ownership restriction (only your own subscriptions). However, it doesn't explicitly compare with alternatives or state when not to use.
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.
Several tools have notably unclear boundaries: ask_pipeworx and ask_pipeworx_beta are explicitly identical right now, and polymarket_edges, polymarket_arbitrage, and bet_research heavily overlap in surfacing betting opportunities. Entity_profile, recent_changes, and compare_entities also share overlapping research scope, making misselection likely.
Most names use snake_case and a roughly readable verb_noun style (resolve_entity, compare_entities, list_categories), but conventions vary: some are bare nouns (entity_profile), some are plain verbs (remember, forget), and ask_pipeworx/pipeworx_* break the pattern. It is readable overall, but not a consistent scheme.
34 tools is far more than the 'trivia' name implies, and most of them (Pipeworx research, Polymarket analysis, memory, subscriptions) are unrelated to trivia. The set reads as an entire platform bundled together rather than a purpose-scoped server.
For the stated trivia purpose, the surface is missing core lifecycle features like quiz sessions, answer validation, or scoring; the few trivia tools are just category/reference lookups. As a general data/research server it is broad, but there are significant gaps and no coherent domain model tying the tools together.