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?
Annotations indicate non-readOnly, non-destructive, but idempotent. The description adds critical behavioral context: the row is deactivated (not deleted) and historical events remain via recent_alerts. This goes beyond annotations and clarifies the actual effect.
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, no wasted words. The first introduces action and constraint, the second explains the behavioral outcome. Perfectly front-loaded and efficient.
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 tool (1 param, no output schema), the description covers purpose, usage constraint, and what happens to the row. It also informs the user about where to find historical data (recent_alerts). No gaps.
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 only parameter 'id' has a description in the schema ('Subscription id (uuid) returned by subscribe.'). The description adds a phrase 'by id' which is redundant but the mention that the id comes from subscribe is helpful. With 100% schema coverage, baseline is 3, and little extra value is added.
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 the action 'Cancel a subscription by id.' It identifies the resource (subscriptions) and distinguishes from its sibling 'subscribe'. However, it does not explicitly differentiate from other related tools like '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 states that ownership is enforced, implying you can only cancel your own subscriptions. It provides a key constraint but does not mention when not to use the tool or suggest alternatives.
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 tool set has several near-duplicate entries (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded; five polymarket_* tools), and the server name implies topography while most tools serve unrelated data lookups, making it hard to select the right tool for a task.
Most tool names use snake_case and a verb-first style, but there are notable exceptions like 'datasets', 'dem', and 'forget', and the 'pipeworx' prefix is applied inconsistently (pipeworx_feedback, pipeworx_trending vs. ask_pipeworx). The pattern is readable but not fully uniform.
With 34 tools, the count is excessive for a server named Opentopography, especially since only 3 tools (datasets, dem, point_elevation) relate to the implied domain. The bulk of tools belong to a general-purpose data and prediction-market service, creating a severe scope mismatch.
For the implied topography domain, the surface is severely incomplete: only dataset listing, a raster fetch, and a point elevation lookup are present, missing expected operations like elevation profiles, point cloud access, or data processing. For the broader Pipeworx domain, coverage is broad but this does not match the server's stated focus.