Look up how any brand surfaces in ChatGPT and Google AI Overviews. Brands, prompts, sources, niches & more.
Scored across 6 tools
The set includes two pairs of aliases: parse_search/search and fetch/parse_get_brand/parse_get_prompt. The descriptions clarify which tool to use, but fetch could easily be mistaken for a generic retrieval tool, and search vs parse_search is redundant. Distinct tools like parse_get_brand and parse_get_stats are clear, but overall there's noticeable overlap.
Primary tools follow a parse_get_* pattern for specific resourcesorestation, and parse_search is a verb-based action. However, the compatibility aliases fetch and search break the pattern and use generic names. The mixed parse_ prefix and inconsistency between get vs search make the naming feel somewhat scattered.
Six tools is a reasonable count for a niche server, but two are compatibility aliases, reducing unique functionality to four. The redundancy makes the count slightly padded, though it remains well within an acceptable range for the domain.
The server covers the core read-only operations for the Parse index: searching, fetching specific brands and prompts, and understanding index stats. It lacks listing or pagination capabilities, but for the stated purpose of marketer research, the surface is largely sufficient without major dead ends.
Compatibility alias that resolves fetch IDs like brand:stripe or prompt:best-crm into JSON-text results with human-readable text.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that the tool is read-only. The description adds that it resolves IDs into JSON-text with human-readable text and that it is a compatibility alias. This is useful but does not disclose potential error behaviour or constraints beyond that.
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 a single, well-structured sentence that front-loads the purpose: 'Compatibility alias that resolves...' It is concise with no filler words and efficiently communicates the core information.
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 tool with readOnly annotation and no output schema, the description covers core purpose and input format. However, it lacks usage context relative to sibling tools and does not specify the full range of accepted ID types. It is adequate but leaves gaps in decision-making.
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 schema only defines 'id' as a string with no description, making schema coverage 0%. The description compensates by providing two example ID formats (brand:stripe, prompt:best-crm), giving the agent concrete understanding of expected input. This is meaningful semantic addition for a single-parameter tool.
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 identifies the tool as a compatibility alias that resolves fetch IDs into JSON-text results, with concrete examples of ID formats (brand:stripe, prompt:best-crm). It is specific about what it does, though it does not explicitly differentiate from sibling tools like parse_get_brand or search.
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 provides no guidance on when to use this tool versus the alternative sibling tools. It states it is a 'compatibility alias' but does not explain when to prefer it or mention any exclusions. This leaves the agent without clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a concise public marketing brief for one brand, including Parse score, strengths, weak spots, top prompts, citation sources, related brands, and next research questions.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context about the 'public' nature and the 'concise' format. It specifies the included data types, which helps set expectations for the response, without contradicting the read-only annotation.
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 entire description is one sentence with a front-loaded action, followed by a clear list of included fields. It conveys all necessary information without unnecessary words.
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 the tool's simplicity (one read-only parameter, no output schema), the description adequately covers what the brief contains including scores, strengths/weak spots, prompts, citations, related brands, and next questions. It could mention the input format, but that is a parameter semantics issue rather than contextual 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 single required parameter 'slug_or_id' has no description in the schema (0% coverage), and the description only indirectly mentions it by targeting 'one brand'. No format, example, or clarification is provided, leaving the parameter semantics under-specified.
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 ('Fetch') and clearly defines the resource ('concise public marketing brief') and scope ('for one brand'). It enumerates the brief's contents, which differentiates it from sibling tools like parse_get_stats and parse_get_prompt that focus on specific data slices.
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 this tool is for retrieving a holistic overview of a brand's AI visibility, but it does not explicitly state when to use it versus alternatives like parse_get_stats or parse_get_prompt. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one public organic prompt by slug when the user wants to inspect the exact AI-search question behind a result.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, and the description's 'Fetch' is consistent with a read-only operation. It adds context about the resource being a 'public organic prompt' and the purpose of retrieving the AI-search question, but it does not disclose error behavior, response shape, or any edge cases. Since annotations cover the safety profile, the added context is modest, earning a 3.
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 a single, well-structured sentence that begins with the action ('Fetch') and conveys the key details in under 25 words. No fluff or repetition; every word adds value.
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 provides a clear purpose and usage scenario. It does not specify return format or errors, but given the simplicity, the core context is adequate. Siblings are also visible to the agent, providing further disambiguation. A 4 reflects the minor missing detail around parameter semantics.
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 input schema has only one parameter, 'slug', with zero description coverage. The description mentions 'by slug' indicating it's the identifier, but provides no information about slug format, origin, or example values. With schema coverage at 0%, the description does not sufficiently compensate, leaving the agent to guess what a valid slug is.
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 explicit verb 'Fetch' and specifies the resource 'one public organic prompt' and the identifying parameter 'slug'. It also ties to a concrete use case ('inspect the exact AI-search question behind a result'), clearly distinguishing it from sibling tools like parse_get_brand or parse_search.
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 includes a clear usage context: 'when the user wants to inspect the exact AI-search question behind a result.' This tells the agent when to invoke this tool. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the public Parse index scale and freshness: tracked brands, organic prompts, and citation observations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers safety. The description adds content scope (freshness, tracked brands, etc.) but does not disclose additional behavioral traits like rate limits or response format. Since it is a read-only, parameterless tool, the bar is low, and the description meets it without adding much beyond the annotation.
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?
One sentence, front-loaded with the main goal, followed by specific dimensions. No filler words or repetition.
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 content categories but does not specify the output format or whether numbers are counts/percentages. With no output schema, a bit more detail on return structure would improve completeness, but for a scale/freshness summary, the current description is adequate.
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 per the rubric. There is nothing to explain, and schema coverage is trivially 100%. The description does not need to add parameter details.
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 specifies a concrete resource (public Parse index scale) and the dimensions covered (tracked brands, organic prompts, citation observations). The verb 'explain' is slightly weak, but the scope clearly distinguishes this tool from siblings like parse_get_brand or parse_search.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies high-level overview but does not mention exclusions or direct the agent to sibling tools for specific queries. This is a clear gap for an agent deciding between stats and specific data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find brands, organic AI prompts, and market niches for marketer research. Use this first when the user names a brand, category, or AI visibility question.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| types | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the scope of the search (brands, prompts, niches) but does not disclose behavioral traits like return format, pagination, or rate limits. Given annotations, it provides some additional context but not rich behavioral detail.
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 sentences, each serving a purpose: the first states the tool's purpose, the second gives usage guidance. No fluff, and the key 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 tool with 3 parameters and no output schema, the description should explain what the tool returns and how to use the parameters. It only gives high-level purpose and usage, missing parameter semantics and return format, which is insufficient for correct invocation.
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 does not explain the query or limit parameters, and only vaguely hints at the types values by listing them in the description without mapping to the parameter name. An agent cannot infer how to construct a correct request.
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 tool finds brands, organic AI prompts, and market niches, giving a specific verb and resource. It also indicates it's for marketer research, and the phrase 'use this first' suggests it's the entry point, though it does not explicitly differentiate from the sibling 'search' tool.
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 explicitly says 'Use this first when the user names a brand, category, or AI visibility question,' providing clear context for when to use it. However, it does not mention when not to use it or name alternative tools, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compatibility alias for parse_search. Use for clients that expect a generic search tool.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint already declared, the annotation covers the safety profile. The description adds the alias relationship to parse_search, but it does not disclose additional behavioral traits such as return format, pagination, or search scope. This is not contradictory, but it provides only minimal extra context beyond the annotation.
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 a single, well-structured sentence that directly communicates the tool's purpose and usage context. It contains no filler or unnecessary details, earning full marks for conciseness.
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 is adequate for a simple alias tool but leaves gaps: it does not describe parameter semantics or return behavior, relying on the existence of parse_search for full context. Given the lack of an output schema and the simplicity of the tool, this is a minimum viable description but not comprehensive.
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 description provides no information about the query or limit parameters, and schema description coverage is 0%. The schema only gives types and constraints, but the description fails to explain the meaning or typical usage of these parameters. Since there are only 2 parameters, the description should compensate but does not.
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 that it is a compatibility alias for parse_search, which clarifies that it performs the same search operation. However, it does not explicitly say 'searches' or describe a resource, relying on the association with parse_search to convey purpose. This distinguishes it from siblings but lacks clear verb-resource specificity.
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 tells when to use it ('for clients that expect a generic search tool') and names the alternative (parse_search). While it gives clear context, it does not state when not to use it beyond implying parse_search is the direct alternative.
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.
parse_search1 field changedInput schema / properties / types / items / enumPrevious value: -[
- "brands",
- "prompts",
- "niches",
- "sources"
-]New value: +[
+ "brands",
+ "prompts",
+ "niches"
+]fetchparse_get_brandparse_get_promptparse_get_statsparse_searchsearch
Add one secure layer between your agents and this server.