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?
The description adds significant value beyond annotations: it explains ownership enforcement and the deactivation (not deletion) side effect. Annotations only indicate non-destructive, idempotent mutation; the description clarifies the concrete impact.
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?
Three concise sentences: first states action, second adds ownership constraint, third explains deactivation. Every sentence adds necessary information with no 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?
For a simple mutation tool with one parameter and no output schema, the description covers purpose, ownership, and side effect. It could mention return value or success indication, but current completeness is sufficient for usage.
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 a single parameter 'id' already described as 'Subscription id (uuid) returned by subscribe.' The description merely says 'by id' without additional parameter detail, so baseline 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 clearly states the action ('Cancel a subscription by id') with a specific verb and resource. It distinguishes the tool from its sibling 'subscribe' by detailing ownership and deactivation behavior.
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 provides explicit context: ownership enforcement ('you can only cancel your own subscriptions') and the deactivation behavior. It implies when to use (you own the subscription) but does not name alternatives for deletion or other scenarios.
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 purposes, but there is meaningful overlap among ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, and deep_research, which all route questions to the same source catalog and could be easily confused. Similarly, ai_visibility_check and scan_competitor_ai_presence overlap, and the many polymarket_* tools require careful reading to distinguish. The descriptions are detailed enough to help, but the set is not cleanly separable.
All names use lowercase snake_case, which is consistent in style, but the pattern is mixed: some tools use verb_noun (search_datasets, list_organizations, validate_claim), while others are bare nouns or noun phrases (entity_profile, dataset_details, recent_alerts, polymarket_edges). This makes the naming readable but not predictable, and it lacks a single clear convention.
At 35 tools, this is a heavy surface, and most of them are unrelated to the server's apparent 'Datagov Uk' purpose—only search_datasets, dataset_details, list_organizations, and organization_details actually serve data.gov.uk. The rest are a general Pipeworx/prediction-market/AI-visibility toolkit bolted onto a government data server, making the count inappropriate for the stated scope.
For the nominal data.gov.uk domain, the four CKAN tools cover search, dataset details, and organization listing, but there is no create/update/delete (datasets are open data, so that is acceptable) and no direct resource download or preview helper despite resource links being returned. More importantly, the overwhelming majority of tools address unrelated domains, so the server's actual coverage is scattered and does not form a coherent complete surface for any single stated purpose.