Read-only CRISP scores and AI visibility data from Third Hemisphere's AI Authority Index.
Scored across 7 tools
Most tools have clearly distinct retrieval purposes: current score, score history, edition results, market standing, edition listing, market listing, and company search. The main possible overlap is between edition results and market standing, since markets appear to be edition sections, but the descriptions clarify the different granularity and use case.
All tools use consistent snake_case with a predictable verb_noun pattern: get_company_authority_score, get_company_score_history, get_edition_results, get_market_standing, list_index_editions, list_markets, and search_companies. The verbs are used consistently according to the operation type.
Seven tools is a well-scoped set for a read-only index API. Each tool covers a distinct retrieval need, and there are no obviously redundant or trivial tools.
The surface covers company scores, score history, edition results, market standings, edition listings, market listings, and company search, which is strong lifecycle coverage for a read-only index. A few deeper cross-links, such as directly retrieving a company's factor readings outside an edition section, are not explicit but can be worked around.
A company's published CRISP score and AI visibility reading in each market the AI Authority Index measures it in, with the month measured and its Standing Report link. Accepts a company name or slug. Read-only. Every result carries its citation and link.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Optional market slug, to return one market's Standing Report with all five factors. | |
| company | Yes | The company's name (e.g. Plenti) or its slug from search_companies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, and the 'Read-only' sentence repeats that rather than adding to it. The description does add useful behavioral detail beyond the annotations — that every result carries its citation and link and that a measurement month is included — which is genuine value for a tool with 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?
Three short sentences, front-loaded with the returned resource then the input and safety note, with no wasted wording. Minor deduction only because terms like 'CRISP score' are used without explanation and the 'Read-only' sentence duplicates the annotation.
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 burden of explaining returns and does so adequately: the score, the visibility reading per market, the month measured, a Standing Report link, and per-result citations. Enough for an agent to know what it receives and how to call it, though the meaning of 'CRISP score' remains undefined.
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 schema already explains both the company (name or slug) and the optional market slug. The description restates 'a company name or slug' and clarifies that omitting market returns all measured markets, which is a marginal add over the schema's 'one market's Standing Report' phrasing — 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 a specific resource (a company's published CRISP score and AI visibility reading per market) with a clear scope ('each market the AI Authority Index measures it in'). It doesn't explicitly distinguish itself from close siblings like get_company_score_history or get_market_standing, though the 'month measured' phrasing implies a current snapshot.
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 implied rather than stated: 'Accepts a company name or slug' indicates the input context and the per-market framing hints at a scoring lookup, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative such as score history for trend queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every dated reading the AI Authority Index has published for a company, oldest first: its rows in each edition and each market's Standing Report. Read-only. Every result carries its citation and link.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company name or slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the 'Read-only' sentence adds little. However, the description adds useful behavioral context beyond annotations: results are ordered oldest first and every result carries its citation and link, which matters in the absence of an 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?
The description is compact and front-loaded: the first sentence establishes the historical scope and ordering, followed by a short safety note and result-citation note. Every sentence contributes information with no obvious waste.
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 simple one-parameter read tool with full schema coverage and annotations covering safety and idempotency, the description is largely complete: it says what is returned, how it is ordered, and that citations/links accompany results. Minor gaps remain around pagination or result volume, but no output schema exists to require that level of detail.
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 only parameter is 'company,' and the schema fully documents it as a company name or slug. The description reinforces that the query is company-scoped but adds no format or semantic detail beyond the schema, so the baseline of 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 states a precise resource and scope: every dated reading for a company, oldest first, covering rows in each edition and each market's Standing Report. This distinguishes it from sibling tools such as get_company_authority_score and get_market_standing by making clear it returns historical readings rather than a current or per-market view.
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 implies historical lookup through 'history' and 'every dated reading,' but it does not explicitly say when to use this tool instead of get_company_authority_score, get_edition_results, or get_market_standing. There are no stated exclusions, prerequisites, or alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The published results of one AI Authority Index edition section: each company's Star Chart cell, CRISP score where it has one, the five factor readings the edition prints, and how many AI answers named it. Read-only. Every result carries its citation and link.
| Name | Required | Description | Default |
|---|---|---|---|
| company | No | Optional: return only rows whose company name contains this. | |
| section | No | The section key, e.g. personal-lending. Defaults to the edition's first section. | |
| edition_slug | Yes | The edition's slug, from list_index_editions, e.g. personal-lending. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so 'Read-only' is largely redundant. The description does add real value beyond annotations by enumerating the returned payload (Star Chart cell, CRISP score, five factor readings, answer counts) and noting every result carries a citation and link.
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 core payload description is front-loaded in the first sentence, with two short supporting sentences. It is dense but every clause describes a distinct returned field rather than padding.
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 does the necessary work of describing return contents and the citation/link guarantee. Gaps remain around result volume, pagination, and empty-match behavior, but nothing critical to invoking the tool 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% with per-parameter descriptions for company, section and edition_slug, so the baseline is 3. The description only echoes 'edition section' and does not clarify filtering semantics, section-key format, or what happens when company matches nothing.
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 a specific resource and scope: the published results of one edition's section, itemizing exactly what each row contains (Star Chart cell, CRISP score, factor readings, answer counts). That distinguishes it well from company-level siblings like get_company_authority_score, though it never names an alternative 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 and no routing to alternatives such as get_company_authority_score or get_market_standing. The agent must infer from the resource noun alone whether to reach for this tool or a company-scoped sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The companies in one market with a Standing Report, most named in AI answers first. Read-only. Every result carries its citation and link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| market | Yes | Market slug from list_markets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so 'Read-only' in the description is mostly redundant. However, 'Every result carries its citation and link' is genuine value beyond the structured fields, telling the agent what comes back with each row in the absence of an 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?
Three short, front-loaded sentences with no filler, and the ordering rule comes early where it matters. The 'Read-only' clause duplicates the annotation and is the one mildly wasteful element.
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 steps in to say each result carries a citation and link, and it covers scope and ordering. The remaining gap is the undocumented limit parameter (default and truncation behavior), which is a minor but real omission for a list-style tool.
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 only 50%: 'market' is documented in the schema itself, while 'limit' has no description anywhere. The description never mentions 'limit' — no default, no mention of the 1-100 cap or whether results are truncated — so it fails to compensate for the coverage gap.
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 specific resource (companies within one market that have a Standing Report) and states the ordering (most named in AI answers first), which is enough to distinguish it from siblings like search_companies or get_company_authority_score. The verb is implied by the title rather than the description, but the returned set is 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?
The phrase 'in one market with a Standing Report' implies a prerequisite (the market must have a Standing Report) but never states when to pick this over search_companies or list_markets. The schema hint 'Market slug from list_markets' supplies the discovery path, so usage is inferable but not spelled out in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every published edition of Third Hemisphere's AI Authority Index, with its markets (sections), publication date, DOI where recorded, and links to its page, results, and open data. Read-only. Every result carries its citation and link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the bar is lower; the description still adds real context by stating 'Read-only' and that every result carries its citation and link, which matters for citation-bearing output. It does not cover ordering or completeness of the edition set, but the added value is genuine.
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 resource and its payload, with no filler. Every clause adds information an agent would otherwise have to guess.
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 parameters and no output schema, the description carries the return-value burden and does so by listing the fields each edition carries. Only ordering and result-set size are unstated, a minor gap for a parameterless list tool.
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.
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+resource — every published edition of the AI Authority Index — and enumerates the payload (markets, publication date, DOI, links). It is clearly distinct from get_edition_results and list_markets, though it doesn't name a sibling 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?
Usage is only implied: an agent can infer this is the enumeration entry point that precedes get_edition_results, but the description never says when to use it, when not to, or which sibling to prefer for a specific edition's results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every market the AI Authority Index measures, with how many Standing Reports it has and when it was last measured. Read-only. Every result carries its citation and link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the 'Read-only' sentence adds nothing new. The one real addition is 'Every result carries its citation and link', which discloses return content — valuable given no output schema — but ordering, completeness guarantees, and pagination behavior remain unstated.
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 compact sentences: scope and returned fields first, then the safety/return assurance. No filler, and the most decision-relevant information is 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 zero-parameter listing tool with no output schema, the description covers what comes back well enough to call it confidently. Minor gaps (result ordering, whether the market list is exhaustive/stable) keep it short of full completeness.
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 to document beyond that fact; the description does not misleadingly suggest any filtering options exist.
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 ('every market the AI Authority Index measures') and what each row contains (Standing Report count, last measured date), which is far more specific than the bare tool name. Scope ('every market') implicitly separates it from the single-market sibling get_market_standing, but no sibling is named 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?
Usage is only implied: an agent can infer this is the enumeration entry point before calling get_market_standing for detail. There is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find companies with a Standing Report in Third Hemisphere's AI Authority Index by name. Read-only. Every result carries its citation and link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the description's 'Read-only' line is redundant. However, the added note that 'Every result carries its citation and link' provides useful output context not present in annotations or an output schema. Pagination and matching behavior remain undisclosed.
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, front-loaded sentences with no waste. The core action and scope appear immediately, followed by safety and result-format notes.
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 0% schema description coverage, the description is incomplete for a two-parameter tool. It does not explain how the name query matches or what limit controls, leaving key invocation details to inference.
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 compensate. It explains that the query is by company name, but says nothing about partial matching, case sensitivity, or the 'limit' parameter and its maximum of 25.
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 gives a specific verb ('Find') and resource ('companies') and narrows scope to companies with a Standing Report in the AI Authority Index searched by name. It is clear but does not explicitly differentiate itself from siblings like get_company_authority_score or get_market_standing.
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 guidance on when to use this search tool versus alternatives such as get_company_authority_score or get_market_standing. The agent must infer that this is for name-based discovery rather than score retrieval.
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_company_authority_scoreget_company_score_historyget_edition_resultsget_market_standinglist_index_editionslist_marketssearch_companiesRead-only AI search visibility data: citations, AEO audits, and advisor insights from AI-Advisors.
Read-only AI search visibility, prompts, citations, competitors, and opportunities from Airefs.
AI visibility for your brand: scores, competitors, prompts, site health and articles.
Read-only AI impact metrics with search, methodology and cited sources. No authentication required.
Add one secure layer between your agents and this server.
