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?
Discloses that the row is deactivated (not deleted) and historical events remain available via recent_alerts. This adds value beyond annotations, which already indicate non-destructive and idempotent behavior.
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 focused sentences with no waste. The first sentence states the action, the second covers behavioral details. 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 single-parameter tool with no output schema, the description sufficiently covers purpose, usage constraint, and behavioral nuance. No gaps remain.
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 parameter 'id' is described as 'Subscription id (uuid) returned by subscribe.' with 100% schema coverage. The description adds useful context linking it to the sibling tool 'subscribe', helping the agent know where to obtain the ID.
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 uses the specific verb 'Cancel' and noun 'subscription', clearly indicating the action and resource. It distinguishes itself from siblings like 'subscribe' and 'list_subscriptions' by being the inverse operation.
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?
Explicitly states the ownership constraint: 'you can only cancel your own subscriptions.' This provides clear context for when to use. Could be improved by mentioning when not to use, but it's sufficient.
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.
Many tools have overlapping purposes, e.g., multiple ask_pipeworx variants and several Polymarket analysis tools. The presence of meta-tools like discover_tools and suggest_questions adds confusion. Distinguishing between tools like entity_profile, compare_entities, and recent_changes requires careful reading of descriptions.
Naming conventions are mixed: some use snake_case (ai_visibility_check, ask_pipeworx), others use underscores (compare_entities, deep_research). Prefixes like pipeworx_ and polymarket_ are inconsistently applied, and there is no clear verb_noun pattern across the set.
With 32 tools, the server is heavily over-scoped for its name 'Yc Rejection'. Only one tool directly relates to that domain. The rest constitute a full data platform, making the count far too high for the implied narrow purpose.
For a server named 'Yc Rejection', the tool set is severely incomplete: only one tool generates rejection text. There are no tools for application management, review, or related tasks. The actual completeness of the underlying platform is irrelevant given the misleading name.