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?
Beyond annotations (readOnly=false, destructive=false, idempotent=true), the description adds that the row is deactivated rather than deleted and that ownership is enforced. It also notes historical events remain available via recent_alerts. However, it doesn't describe error behavior (e.g., invalid id, unauthorized cancellation) or return value, which are minor gaps given the simple scope.
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 sentences, each earning its place: the core action, the ownership constraint, and the soft-delete behavior with history availability. No fluff, front-loaded.
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 one-parameter mutation tool with strong annotations, the description covers the essential: what it does, constraints, and side effects. The mention of recent_alerts integrates well with sibling tools. No output schema exists but the return value is predictable for a cancel operation, so no gap is significant.
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% — the only parameter 'id' is fully described as 'Subscription id (uuid) returned by subscribe.' The description does not add any additional parameter semantics, so 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 clearly states the action ('Cancel a subscription by id') with a specific verb and resource, and distinguishes it from siblings like subscribe (creation) and list_subscriptions (viewing). The deactivation detail further separates it from a destructive delete.
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 gives clear context: it's the cancellation tool, and ownership is enforced. It implies using recent_alerts for historical events after cancellation, but does not explicitly name alternatives like 'use list_subscriptions to see your subscriptions' or 'use subscribe to create a subscription.' This is clear but lacks explicit when-not/alternative guidance.
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.
Several tools have overlapping purposes (e.g., ai_visibility_check and scan_competitor_ai_presence; ask_pipeworx, ask_pipeworx_grounded, and deep_research). However, detailed descriptions and specific use cases help agents distinguish between them in most cases.
All tools use snake_case naming consistently, e.g., ask_pipeworx, compare_entities, govcon_agency_landscape. The pattern is uniform across the entire set.
With 33 tools, the set is slightly over the typical well-scoped range. While many tools serve distinct purposes, some seem redundant (e.g., memory tools, multiple research tools), making the count feel a bit heavy.
The tool surface covers a broad range of research and intelligence domains but lacks actionable tools for core government contracting tasks like submitting bids or tracking contract performance. Several obvious operations (e.g., user profile management, submission tools) are missing.