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 already indicate this is a non-read, non-destructive, idempotent operation. The description adds valuable behavioral detail: the row is deactivated rather than deleted, and historical events stay available. This goes beyond annotations and clarifies the soft-delete side 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, front-loaded with the primary action, and each sentence adds distinct value: what is done, who can do it, and what happens to the row. 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 single-parameter mutation with strong annotations and no output schema, the description covers the essential context: ownership, deactivation behavior, and historical availability via recent_alerts. Nothing critical is missing.
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 input schema already fully describes the 'id' parameter (uuid returned by subscribe). The description's 'by id' adds no new semantics. With schema coverage at 100%, the baseline of 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 starts with a specific verb+resource: 'Cancel a subscription by id.' It clearly distinguishes from sibling tools like subscribe and list_subscriptions by focusing on 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?
Provides clear usage context: 'Ownership is enforced — you can only cancel your own subscriptions' and notes that historical events remain available via recent_alerts. This implies when to use the tool and hints at alternatives, though it doesn't explicitly name 'use list_subscriptions to view your subscriptions'.
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.
All 33 tools have clearly distinct purposes, even those that seem related like ask_pipeworx, ask_pipeworx_grounded, and deep_research are well-differentiated by use case and behavior. Memory tools (remember/recall/forget) and subscription tools (subscribe/unsubscribe/list_subscriptions/recent_alerts) are similarly distinct.
All tools use snake_case, but naming patterns are mixed: some are single verbs (forget, recall), some verb_noun (query_layer, search_datasets), some noun_noun (entity_profile, layer_info), and some longer phrases (polymarket_kalshi_spread, scan_competitor_ai_presence). While readable, the inconsistency makes the set feel less coherent.
With 33 tools, the surface is overly broad for a server named after a specific ArcGIS dataset. Many tools are unrelated to the core purpose (e.g., polymarket tools, npm scanning, AI visibility), making the count feel bloated and unfocused.
For the stated ArcGIS Branson focus, only 3 tools (search_datasets, query_layer, layer_info) are relevant, offering only read access. The rest are a miscellaneous collection from the Pipeworx ecosystem and other domains, leaving obvious gaps in GIS functionality and no write or analysis capabilities.