Read-only cancellation guides, mailing addresses and letters for thousands of subscriptions.
Scored across 4 tools
Each tool maps to a distinct verb+resource: search companies by name, fetch one company's guide, generate one company's letter, list category hubs. There is no overlap between fetching a guide and fetching a letter, since the descriptions make clear one is informational and the other is a templated artifact. An agent can pick correctly from names alone.
All four names are snake_case verb_noun (search_companies, get_cancellation_guide, get_cancellation_letter, list_categories). The two get_* tools differ only by their resource noun, which reinforces rather than muddies the pattern.
Four tools is a tight, well-scoped surface for a read-only cancellation-guide lookup service. Nothing appears redundant, and each tool covers a clearly different lookup path (search, guide, letter, categories).
The core path — search a company, read its guide, produce a letter, browse categories — is fully covered with no dead ends, and the slug handoff between search_companies and get_cancellation_guide is explicit. Minor gap: list_categories returns only counts and hub URLs, so there is no tool to enumerate the companies inside a category without going back to search.
How to cancel one company's subscription or membership: how it takes cancellations, the notice period, the traps to check first, billing-partner notes, sources, when the facts were verified, the mailing address(es) on file and the guide and address page URLs. Accepts a company slug from search_companies (merged duplicate slugs resolve to the current one).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Company slug, for example "netflix". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by listing exactly what the guide contains and clarifying that duplicate slugs are resolved to the current company.
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?
The description is front-loaded with the core purpose and then packs the return contents into a single dense but efficient sentence. Because there is no output schema, listing the guide's contents is necessary rather than wasteful.
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, read-only tool with no output schema, the description is complete: it explains the input source, duplicate-slug behavior, and the full set of returned guide information. Nothing material an agent needs in order to call it correctly appears to be 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?
Schema coverage is 100%, so the slug parameter is already documented in the input schema. The description adds meaning beyond the schema by stating that the slug should come from search_companies and that merged duplicate slugs resolve to the current one.
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 states a specific verb and resource: it returns a cancellation guide for one company, including cancellation method, notice period, traps, billing-partner notes, sources, verification dates, mailing addresses, and URLs. It is clearly distinct from search_companies, which supplies the slug, and from get_cancellation_letter, which would produce a letter rather than a guide.
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 explicitly says the slug comes from search_companies, giving clear context for how to obtain the required input. It also explains that merged duplicate slugs resolve to the current one, but it does not explicitly compare itself with get_cancellation_letter or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A plain-text cancellation letter for one company, built from the same template as Postbye's free letter tool, plus where to send it. Fields not supplied stay as [bracketed placeholders] to fill in. Nothing is stored.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Company slug from search_companies. | |
| customer_name | No | Your full name as it appears on the account (optional). | |
| account_number | No | Account, membership or reference number (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the description is not carrying the safety burden. It still adds real value beyond them: unfilled fields remain as bracketed placeholders and 'Nothing is stored', which tells the agent about output shape and the absence of persistence — neither is derivable from the annotations.
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 short sentences, front-loaded with what the tool returns, then the placeholder contract, then the no-storage guarantee. No filler and nothing repeated from the schema or annotations.
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?
With no output schema, the description correctly compensates by describing the return value (a plain-text letter plus where to send it). It does not cover failure behavior for an unknown slug, but for a simple read-only generator with one required parameter, the coverage is nearly complete.
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%, so the baseline is 3. The description goes one step further by explaining what happens to the two optional parameters when omitted — they appear as [bracketed placeholders] rather than failing or being silently dropped, which is behavior the schema does not state.
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 states a specific verb+resource: it produces a plain-text cancellation letter for one company, plus the mailing address. It distinguishes itself implicitly from get_cancellation_guide (letter vs. guidance) and from search_companies (slug lookup) but never names those siblings, so the separation is left to inference.
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?
There is no explicit 'use this when...' guidance and no named alternative. The closest signal is the schema's slug description pointing at search_companies, which lives in the schema, not the description. An agent must guess whether to call this or get_cancellation_guide first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The category hubs of the cancellation guides (streaming, gyms, phone and internet, insurance and more) with the number of guides in each and the hub URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine value beyond them by disclosing the return shape: per-category guide counts and hub URLs, which matters more here since there is no output schema.
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?
A single sentence with no waste, front-loading what the tool returns. The parenthetical example list is slightly padded but concretely useful for understanding what a 'category hub' is.
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 zero-parameter read-only listing tool with no output schema, describing the returned fields (categories, counts, URLs) is the key information and it is present. Minor gaps remain: no mention of ordering, total count, or that this is the natural starting point for navigating the guide set.
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 tool takes zero parameters, which is the baseline-4 case; the empty schema leaves nothing to misinterpret. The description correctly implies no inputs are needed.
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?
States a specific resource (the category hubs of the cancellation guides) and the payload returned (guide count per category plus hub URL), with concrete examples of what a category is. It is clearly distinct from siblings like get_cancellation_guide and search_companies, though it never says so explicitly.
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?
There is no when-to-use guidance: nothing says this is the discovery entry point before calling get_cancellation_guide, and no sibling is named as an alternative. The listing nature implies a browse/discovery use, but the agent must infer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find companies by name (for example "netflix" or "planet fitness") among the subscriptions and memberships Postbye has a cancellation guide for. Returns each match's slug, category, how the company takes cancellations and the guide URL. Use the slug with get_cancellation_guide.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matches (1 to 10). | |
| query | Yes | Company or service name, or part of it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's added value is the return contract: slug, category, cancellation method, and guide URL. That is the useful extra context. It doesn't mention pagination, empty results, or ranking behavior, keeping it below 5.
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 tight sentences: purpose and scope first, return fields second, next-step routing last. No filler and no repetition of the schema.
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?
With no output schema, the description fills that gap by enumerating the returned fields, and it closes the loop with the follow-up tool. For a two-parameter read-only search, nothing an agent needs before calling 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?
Schema coverage is 100%, so both parameters are already documented, including partial-name matching and the 1–10 limit. The description adds value by showing that brand-style names ('planet fitness') and service names ('netflix') both work, clarifying what to put in the query field beyond the schema's generic phrasing.
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?
States a specific verb and resource ('Find companies by name') plus the scope ('among the subscriptions and memberships Postbye has a cancellation guide for'), and names the sibling that consumes the output ('Use the slug with get_cancellation_guide'). Despite a title that says 'Search cancellation guides', the description makes clear the object being searched is companies, which an agent can distinguish from get_cancellation_guide and list_categories.
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?
Usage is clearly implied and partly explicit: search by company name, then pass the returned slug to get_cancellation_guide. Concrete example queries ('netflix', 'planet fitness') anchor when this tool applies. It lacks an explicit when-not statement (e.g., what to do when there is no guide for a company), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_cancellation_guideget_cancellation_letterlist_categoriessearch_companiesRead-only opt-out guides, removal routes for 950+ data brokers, and privacy library search.
Fail-closed refund, cancellation, return, and trial checks for 100 US subscription vendors.
Cancel or cut any subscription: exit steps, cheaper plans, alternatives and the cheapest stack.
Read-only ranked lists, product facts, alternatives and comparisons for software, apps and books.
Add one secure layer between your agents and this server.