Read-only Who AI Sends Buyers boards. Same published scores as the site. No new model runs.
Scored across 7 tools
Each tool maps to a distinct retrieval shape: methodology, single brand, full category board, movers, per-question breakdown, and two list endpoints. The only mild friction is granularity overlap between get_brand, get_question, and get_category_board, which all return brand scores at different slices, but the descriptions make the boundary reasonably clear.
Every tool follows a consistent snake_case verb_noun pattern (get_/list_/describe_ + object), with singular objects for single-item lookups and plural for lists. No style mixing anywhere in the set.
Seven tools is well-scoped for a read-only published-data API covering boards, questions, brands, movers, and methodology. Each tool earns its place with no redundant endpoints.
The read-only surface covers discovery (list_categories, list_questions), retrieval (get_category_board, get_question, get_brand, get_movers), and methodology transparency. The main gap is the absence of any brand listing or search, so an agent must already know exact brand names since unknown names return no score.
The published measurement method. No scores.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the negative detail "No scores"; it says nothing about the shape, length, or nature of the returned methodology content.
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?
It is only two fragments, so nothing is padded, but the terseness reads as under-specification rather than efficiency. "No scores" is front-loaded without context explaining why scores would otherwise be expected.
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 and no annotations covering return content, the description is the only source of information about what an agent receives, and it only says what is not returned. For a documentation-lookup tool an agent needs to know the content type at minimum.
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, so there is nothing for the description to disambiguate; baseline 4 applies. The empty schema is self-explanatory and the description does not mislead about inputs.
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 published measurement method" largely restates the name describe_method without a clear verb or explanation of what is actually returned; it never says whether this returns documentation text, a citation, or metadata. "No scores" is the only distinguishing detail, and it describes what is absent rather than what the tool does.
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 when-to-use guidance and no sibling tool is named. "No scores" implicitly steers an agent away from expecting data, which nudges toward get_movers or list_questions, but the agent must infer that routing on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One reviewed brand's row on each board it is scored on. Unknown names are not given a score.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral fact beyond that: results are returned per board, and an unknown brand name yields no score rather than an error. It says nothing about what the row contains or whether the brand must be pre-reviewed versus merely existing.
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 short sentences with the resource scope front-loaded and the negative-case behavior trailing. No filler, though 'row on each board' is terse to the point of ambiguity about the return shape.
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 lookup tool with one opaque parameter and no output schema, the description leaves the return payload entirely undefined beyond 'row on each board' – an agent cannot tell what fields or how many rows come back. Combined with zero parameter documentation, it is under-specified for correct invocation even allowing for the annotations covering safety.
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 0% for the single `brand` parameter, so the description must carry the meaning and largely does not. 'Unknown names are not given a score' implies the value must match an existing reviewed brand, but it never mentions the required slug form (lowercase, digits, hyphens), length limit, or case sensitivity enforced by the schema pattern.
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 names the resource (one reviewed brand) and the retrieval scope (its row on each board it is scored on), so an agent can tell it fetches per-board brand scoring data. It does not differentiate itself from siblings like get_category_board or get_movers, so the purpose is clear but not sibling-distinguishing.
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 statement of when to use this tool versus get_category_board, get_movers, or get_question. The only conditional sentence ('Unknown names are not given a score') is an outcome/error note, not usage guidance or a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The published category board: brands ordered as on the website, with the same counts. Empty when nothing has been published.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower; the description still adds real behavior by specifying the ordering is the website's ordering, counts match the site, and the result is empty when nothing is published. What it omits is the shape of the returned data and whether this is a cached snapshot or live read.
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 short clauses, front-loaded with the resource and payload, followed by the one edge case that matters. No filler, no restatement of the tool name.
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 one required enum parameter, no output schema, and read-only annotations, the description covers the payload and the empty-result case adequately. It is incomplete on the one thing the schema does not carry: the meaning of the category values and when this tool is the right choice among its siblings.
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 0% and the single required parameter is never addressed in the description beyond the word "category" in the tool's subject. It does not explain what the six enum values denote, whether unpublished categories return empty, or whether the value is case/slug sensitive, so it fails to compensate for the undocumented 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 published category board: brands ordered as on the website, with the same counts" names a concrete resource and its contents, so an agent knows it retrieves a per-category brand listing with counts rather than a single brand (get_brand) or a category list (list_categories). The retrieval verb is only implicit, but the resource and payload are unambiguous.
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 only implied: you call it for a category to get its published board. No sibling is named as an alternative, and there is no guidance on when to prefer get_brand or list_categories, nor any prerequisite about what "published" means in workflow terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Week-over-week brand movers using the same rule as the movers page. A short history returns no movers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Risers and fallers each, per board. Default 3, the page cap. | |
| category | No | Board id. Omit for every board. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral value by disclosing the consistency guarantee ('same rule as the movers page') and the empty-result failure mode for short histories, which an agent cannot infer from any structured field.
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 short sentences, front-loaded with the core purpose and followed by the one caveat that matters. The phrase 'the movers page' is slightly opaque as a substitute for a concrete explanation of the ranking rule, costing a point.
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?
There is no output schema, so the description ideally would sketch the return shape (e.g., risers and fallers per board), which it only indirectly conveys via the parameter text. For a simple two-optional-parameter read tool this is adequate but leaves the result structure implicit.
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% and the parameter descriptions are unusually informative, explaining that 'limit' is risers and fallers each and that 'category' is a board id with omission meaning all boards. The tool description adds nothing further about the two parameters, so the baseline 3 applies.
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 names the resource and the metric precisely: 'Week-over-week brand movers', which clearly distinguishes it from siblings like get_brand or get_category_board. The verb is implied rather than stated ('get'), and the reference to 'the movers page' assumes UI context an agent may not have.
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 clause 'A short history returns no movers' is a useful precondition that tells the agent when the tool will yield nothing. However, there is no explicit when-to-use guidance relative to siblings (e.g., get_brand vs. this) and no statement of what history length is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How often each brand is named on one published question. The slug is the question page slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered without the text. The description adds that only published questions are addressable and that the result is per-brand mention frequency, which is useful context beyond the annotations, though it never clarifies the response shape or what happens for an unpublished or unknown slug.
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 short sentences with no padding, but the ordering is backwards: the result metric is front-loaded while the action and resource selection come second. The second sentence is a fragment that spends words on the one thing the schema already names.
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 carries the full burden of explaining returns, and it does gesture at the returned data (brand mention counts per question). However, for a tool whose name promises a question record, an agent cannot tell whether it gets the question itself, a brand-frequency breakdown, or both, which is a material ambiguity left unresolved.
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 0%, so the description must carry the parameter meaning, and it does partially by identifying slug as 'the question page slug'. It does not explain the lowercase-hyphen format constraint, the 80-character limit, or where an agent obtains a valid slug, leaving the format rules to the schema pattern alone.
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 says the tool operates on 'one published question' and implies a retrieval by slug, but it never states the action with a verb — it leads with a result metric ('How often each brand is named'), which reads more like an aggregation than a single-record fetch. The name get_question and the sibling list_questions suggest a record retrieval, so the purpose is inferable but not stated.
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 and no mention of the obvious alternatives: list_questions for enumerating questions or get_brand for brand-level data. The only guidance is the parenthetical about the slug, which is parameter information rather than usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Who AI Sends Buyers category boards and their public URLs. No scores.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description contributes the useful scoping note that no scores are returned and that URLs are exposed, but says nothing about ordering, pagination, or whether the list is exhaustive.
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 short sentences, zero filler, with the resource identified first and the return-content caveat trailing. Every clause 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?
For a parameterless list tool with no output schema, the description does the necessary work: it identifies the collection and states the two things returned (boards and public URLs). Only minor gaps remain around ordering and result size.
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, so there is no parameter semantics to add; baseline 4 applies. Nothing in the description misleads about inputs.
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 (List) and resource (the 'Who AI Sends Buyers' category boards) and adds what the caller gets back (public URLs). It implicitly contrasts with the singular get_category_board sibling, but never names or explains that distinction 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 phrase 'No scores.' implies this is the lightweight discovery call to use before drilling into a specific board, but the guidance is only implied. There is no explicit when-to-use, when-not-to-use, or named alternative such as get_category_board.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the fixed buyer questions on a board, or every question. No scores.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Board id. Omit for every question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a safe read-only, non-destructive, closed-world operation. The description adds useful behavioral context with 'fixed' and 'No scores', but it does not describe ordering, pagination, or the exact response shape.
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 and front-loads the core action and scope. It is efficient, though the phrase 'fixed buyer questions' could be slightly clearer about what is being returned.
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?
This is a simple read-only tool with one optional parameter and no output schema, and the annotations already cover safety behavior. The description is adequate for calling it correctly, though it could say more about what a question object contains beyond the absence of scores.
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 category parameter and its enum values are already documented. The description restates that questions can be scoped to a board or retrieved for every question, but it does not add syntax or clarify the mismatch between the parameter name 'category' and its schema description 'Board 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 a specific verb and resource: list fixed buyer questions on a board or every question. It clearly distinguishes the all-questions mode from the board-scoped mode, though it does not explicitly differentiate itself from siblings such as get_question or 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?
The phrase 'on a board, or every question' implies that omitting the category parameter lists all questions, matching the schema. However, it gives no explicit guidance on when to use this instead of get_question, get_category_board, or list_categories.
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.
describe_methodget_brandget_category_boardget_moversget_questionlist_categorieslist_questionsPublic board of agent questions, attempts and verified results. Read-only, no API key.
COMING SOON: indexed search, 8,700+ boards. Apify $5 credit. Free 135-board scan.
Search 33 AI data buyers and check which programs' published rules a company meets. Read-only.
Read-only CRE prospects, listings, campaigns, reporting, broker search, and resources.
Add one secure layer between your agents and this server.