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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ownership enforcement and deactivation (not deletion) with historical availability. Adds value beyond annotations (readOnlyHint=false, destructiveHint=false) by explaining the row state.
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-loaded with verb and resource. 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?
Complete for a simple tool with full schema coverage and annotations. Explains all necessary behavioral and contextual aspects.
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 covers 100% of parameters with description. The description adds no additional parameter semantics beyond what schema provides.
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?
Clearly states verb 'Cancel' and resource 'subscription by id'. Distinguishes from siblings like 'subscribe' and 'list_subscriptions' by indicating cancellation and ownership enforcement.
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?
States ownership constraint and deactivation behavior. Provides context but does not explicitly list alternatives or when-not-to-use. However, the purpose is straightforward.
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 distinct scopes, and the long cross-referencing descriptions help a lot. However, ask_pipeworx_beta is currently an exact duplicate of ask_pipeworx by the server's own description, and the polymarket_* family plus ask_pipeworx/ask_pipeworx_grounded/deep_research have overlapping boundaries that could mislead an agent.
The vast majority follow a clear verb_noun snake_case pattern like get_odds, list_sports, resolve_entity, and subscribe. A few exceptions such as odds_api_quota, pipeworx_feedback, polymarket_arbitrage, and recall break the pattern slightly, but the overall convention is predictable.
37 tools is well past the 25+ threshold and feels bloated for a server named 'Odds Api'. Many tools are meta-platform utilities — memory, feedback, trending, dependency scanning, llms.txt generation — that have no obvious connection to an odds API and make the surface hard to navigate.
The odds domain is well covered: list_sports, get_events, get_odds, get_event_odds, get_scores, quota tracking, and subscriptions form a coherent read/monitor workflow. Minor gaps exist — no historical odds or a single-event detail endpoint — but agents can complete core odds research and monitoring tasks without dead ends.