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?
The description adds value beyond annotations: it explains that the row is 'deactivated (not deleted)' and that 'historical events stay available via recent_alerts.' This aligns with the idempotentHint (true) and destructiveHint (false) 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-loaded with the main action. No superfluous words; every sentence provides essential information.
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's simplicity (1 required param, no output schema), the description adequately covers the effect, ownership rule, and lifecycle implications. No missing details.
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 coverage is 100% with the id parameter described. The description adds context that ownership is enforced, implying the id must belong to the user, enhancing understanding of the parameter's constraints.
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 action (cancel) and resource (subscription). It distinguishes itself from sibling tools like 'subscribe' and '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?
The description mentions 'Ownership is enforced — you can only cancel your own subscriptions,' which clarifies when to use the tool. It doesn't explicitly state alternative scenarios or when not to use, but for a simple tool the guidance is adequate.
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 ask_pipeworx, ask_pipeworx_beta, and ask_pipeworx_grounded trio are nearly indistinguishable, with beta currently behaving identically to the stable version. Entity_profile, recent_changes, and compare_entities also overlap heavily as multi-source company research tools, and the six polymarket tools create additional boundary confusion.
Most tools use snake_case, but there is no consistent verb_noun pattern: some are imperative phrases (ask_pipeworx, bls_get_series, resolve_entity), while others are noun phrases (entity_profile, pipeworx_feedback, polymarket_edges, recent_alerts). Even within the bls_* family, bls_latest breaks the verb pattern established by bls_get_series and bls_search.
35 tools is well above the 25+ threshold for 'too many', and the server is named Bls yet only four tools actually serve BLS data. Most of the remaining tools cover unrelated domains like Polymarket arbitrage, memory, feedback, and general Pipeworx routing, making the count feel inflated for the apparent purpose.
The four BLS-specific tools cover search, browse, historical series fetch, and latest value, but there is no multi-series fetch or series metadata detail, which is a notable gap for a BLS-focused server. The broader Pipeworx toolset is extensive, but the lack of a coherent stated domain makes completeness hard to evaluate as a unified surface.