Score pages against 11,485 public taxonomy categories by embedding similarity. $0.05/call via MCP.
Scored across 5 tools
Each tool has a clearly distinct purpose: taxonomy discovery, category lookup, scoring, pass/fail gating, and phrase bank retrieval. Overlaps like score's included phrase bank are explicitly separated from the standalone phrases tool.
All names share the consistent topic_scorer_ prefix and snake_case style, making them easy to group. The suffix mixes verbs (find, gate, score) with nouns (phrases, taxonomies), which is a minor deviation from a strict verb pattern.
Five tools is well-scoped for a focused topic-scoring service. Each tool earns its place and there is no obvious bloat or redundancy.
The surface covers the full workflow: discover taxonomies, find categories, score text, gate content, and retrieve phrase banks. No critical operation appears to be missing for the stated purpose.
Finds categories whose path contains the query (case-insensitive substring), optionally within one taxonomy. Free. Returns up to limit hits with id and path; pass the id as category to the paid tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words to look for in category paths. | |
| taxonomy | No | Taxonomy of the target category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavior: matching is case-insensitive, matching is on category paths, taxonomy filtering is optional, the tool is free, and results are capped at `limit` and include id and path. It does not cover rate limits, error behavior, or ordering, but it covers the essential runtime behavior well.
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 tightly packed sentences, front-loaded with the main verb and resource, then the key qualifiers and downstream usage. Every sentence earns its place and nothing is redundant.
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?
Given there is no output schema and no annotations, the description does a good job of stating what the tool returns (hits with id and path) and how to chain it to paid sibling tools. Minor gaps include no mention of empty-result behavior or any pagination/ordering beyond the limit, but for this tool's simplicity, the definition 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 description coverage is 67%, so the description must add value beyond the schema. It does: it clarifies that `query` is matched as a case-insensitive substring, that `taxonomy` is optional, and that `limit` caps the number of returned hits. This meaningfully supplements the schema descriptions.
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 a specific verb ('Finds') and resource ('categories whose path contains the query'), with explicit matching semantics: case-insensitive substring. It is clearly distinct from the sibling scoring tools, though it does not name them 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?
The description gives clear context: this is a free lookup tool to find categories, optionally within a taxonomy, and the returned id feeds the paid tools. It does not explicitly state when NOT to use it or list alternatives, 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.
Pass/fail check: does the text rank within the top min_rank categories of its target taxonomy? Returns pass, the target's rank and gap to #1, the taxonomy's top five, and the unused phrases to work in. Use it as a content-pipeline gate. Paid, $0.05/call; read-only and safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | Score the whole text as the mean of 8,192-char chunks instead of only the first 8,192 chars. | |
| text | Yes | The page or draft text to score, as plain text or HTML (tags are stripped). 1 to 32768 characters. URLs are not fetched; send the content. | |
| phrases | No | Phrase bank size for the target category (0 skips it). | |
| category | Yes | Target category id, full path, or a unique path substring within the taxonomy (use topic_scorer_find to look one up). | |
| min_rank | No | Highest passing rank. | |
| taxonomy | Yes | Taxonomy of the target category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and it delivers: it discloses that the tool is paid at $0.05/call, read-only, and safe to retry, and it spells out the pass/fail result plus returned diagnostic data. This goes well beyond the schema, which only defines parameters.
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 terse sentences front-load the decision-purpose, then the return payload, then the usage/cost/safety note. No filler or repeated schema content.
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?
The description explains purpose, pass condition, return data, cost, and retry safety, which is strong for a stateless scoring tool. However, there is no output schema and the description does not fully specify the shape or types of 'pass', rank, gap, top five, or unused phrases, so an agent must infer some return structure.
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 description coverage is 100%, so the parameters are already fully documented. The description mentions min_rank and the target taxonomy but does not add semantic detail beyond the schema, which is the baseline for this dimension.
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 first sentence names a specific verb and object ('Pass/fail check: does the text rank within the top min_rank categories of its target taxonomy?') and the second lists the exact return values. This clearly distinguishes it from scoring, lookup, and taxonomy-list siblings by framing it as a gate.
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?
'Use it as a content-pipeline gate' gives a clear intended context, and 'read-only and safe to retry' adds operational guidance. It does not explicitly state when to prefer a sibling tool such as topic_scorer_score, so exclusion guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the ranked phrase bank for one category: 1 to 4 word phrases a page squarely about that category would contain, ordered by similarity to the category. Use it to seed a brief. Paid, $0.05/call; read-only and safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Bank size. | |
| category | Yes | Target category id, full path, or a unique path substring within the taxonomy (use topic_scorer_find to look one up). | |
| taxonomy | Yes | Taxonomy of the target category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that the call is paid ($0.05/call), read-only, and safe to retry. This is valuable operational context beyond the schema, though it does not mention potential errors, rate limits, or exact response structure.
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 two sentences with no fluff. The primary action and output are front-loaded, followed by the use case and important operational caveats (cost, read-only, retry safety). Every sentence earns its place.
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?
The tool is simple and the description covers what the tool returns, how to use the result, and key operational behavior. Since there is no output schema, the description could be more explicit about whether the result includes similarity scores alongside phrases, but overall it provides enough for an agent to select and invoke the tool effectively.
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 description coverage is 100%, so the baseline is 3. The description adds context about the tool's output but does not add meaning beyond what the schema already provides for the parameters. The 'n' parameter is only described as 'Bank size,' which is adequate but not enriched.
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 verb and resource: 'Returns the ranked phrase bank for one category.' It also specifies the phrase length range (1 to 4 words) and ordering ('ordered by similarity to the category'), which makes the tool's purpose unambiguous and distinct from siblings like topic_scorer_find or topic_scorer_score.
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 an explicit use case: 'Use it to seed a brief.' Additionally, the category parameter documentation points to topic_scorer_find for looking up a category, giving the agent a clear path to a sibling tool. It does not explicitly state when not to use this tool, 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.
Scores text against every category in all six taxonomies (one embedding, cosine similarity) and returns the top per rows per taxonomy. With taxonomy and category it also returns the target's rank, score, gap to #1, and a phrase bank split into phrases the text already uses and phrases it does not. Read the rank and the gap, not the raw percent (scores compress into a 70 to 90 band). Paid, $0.05/call; read-only and safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| per | No | Rows per taxonomy. | |
| full | No | Score the whole text as the mean of 8,192-char chunks instead of only the first 8,192 chars. | |
| text | Yes | The page or draft text to score, as plain text or HTML (tags are stripped). 1 to 32768 characters. URLs are not fetched; send the content. | |
| phrases | No | Phrase bank size for the target category (0 skips it). | |
| category | No | Target category id, full path, or a unique path substring within the taxonomy (use topic_scorer_find to look one up). | |
| taxonomy | No | Taxonomy of the target category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states it is read-only, safe to retry, and paid ($0.05/call). It also reveals behavioral nuance: scores compress into a 70-90 band, so raw percent is misleading—an important caution for the agent. This is comprehensive for a non-destructive tool.
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 exactly two sentences with no filler. The core action and output are front-loaded; the extra conditions and interpretation guidance follow logically. Every word earns its place.
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?
The description covers the main function, conditional behavior, result interpretation, cost, and safety. It lacks an explicit return format, but given the absence of an output schema, it provides enough for an agent to understand what to expect. It could mention that taxonomy and category are required together, but the wording 'With taxonomy and category' implies that.
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 adds meaning by explaining that supplying both taxonomy and category triggers the extended output, which is not obvious from the schema alone. It also repeats the phrase-bank semantics but does not add syntax details beyond the schema.
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 opens with a clear verb-resource pairing: 'Scores text against every category in all six taxonomies.' It also specifies the output (top rows per taxonomy) and the conditional extended output, distinguishing it from sibling tools like find, gate, phrases, and taxonomies.
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 implicit usage context: it notes that providing taxonomy and category enables extended output, and it advises interpreting results via rank/gap rather than raw percent. However, it does not explicitly contrast with sibling tools or state when not to use this tool, leaving some routing to the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the six taxonomies with their label and category count. Free. Call it first to pick the taxonomy for topic_scorer_find.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool is free, lists exact returned data (label and category count), and implies a read-only listing through 'Lists.' This covers the key behavioral traits for a zero-parameter metadata tool.
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 two short sentences with no filler. The core action and output are front-loaded, and the cost and usage hint fit in one word ('Free') and one imperative ('Call it first').
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 listing tool with no output schema, the description is complete: it states what the tool returns, that it is free, and exactly how it fits into the workflow with topic_scorer_find. No critical information 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 tool has zero parameters, so the baseline is 4; the description appropriately omits parameter details. There is nothing further needed because the input schema is empty.
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 a specific verb ('Lists') paired with a concrete resource ('the six taxonomies') and defines the output contents ('label and category count'). It clearly distinguishes this tool from siblings like topic_scorer_find and topic_scorer_score by describing a metadata-listing 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?
It gives an explicit call order: 'Call it first to pick the taxonomy for topic_scorer_find.' This is clear context for when to use it, though it does not explicitly discuss when not to use it or compare against all sibling tools.
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.
topic_scorer_findtopic_scorer_gatetopic_scorer_phrasestopic_scorer_scoretopic_scorer_taxonomiesGEO scores and content-rewrite suggestions for any web page, as MCP tools.
Scrape, crawl, map and extract the web. Pay per call in USDC, no account or API key.
Pay-per-call AI evaluation MCP server. Score LLM outputs against benchmark rubrics via Workers AI.
Turns any URL into SEO metadata, contacts, tech stack, and AI-ready Markdown, in one call.
Add one secure layer between your agents and this server.