Look up how any brand surfaces in ChatGPT and Google AI Overviews. Brands, prompts, sources, niches & more.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.8/5 across 6 of 6 tools scored.
Most tools have distinct purposes: parse_get_brand fetches brand briefs, parse_get_prompt fetches prompts by slug, parse_get_stats explains the index, and parse_search does searching. However, the 'fetch' alias overlaps with parse_get_brand and parse_get_prompt by resolving IDs, causing potential ambiguity.
The four parse_* tools consistently follow a verb_noun pattern (parse_get_*). However, the two compatibility aliases 'fetch' and 'search' break this pattern, introducing minor inconsistency.
Six tools is a well-scoped set for a read-only research server focused on parsing and searching. Each tool serves a clear purpose without unnecessary bloat.
The server covers core read operations: searching, getting brand details, getting prompt details, and retrieving index statistics. Minor gaps exist (e.g., no direct tool for listing all brands or prompts), but the search tool handles discovery.
fetchFetchACompatibility 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 covers safety. The description adds useful context about ID formats and output type, but does not disclose behavior on invalid IDs, pagination, or how this relates to the underlying parse tools. With annotations present, this is adequate but minimal.
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 sentence that front-loads the purpose and includes only necessary information. No fluff or redundancy.
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 simple schema (one parameter), readOnly annotation, and no output schema, the description is largely complete. It could have explicitly noted that this is a generic alias for the parse_* tools, but the examples make this inferable.
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 lists an 'id' string with no description. The description compensates by providing concrete examples (brand:stripe, prompt:best-crm), which clarifies the expected format and meaning of the parameter.
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 resolves fetch IDs into JSON-text results, with specific examples (brand:stripe, prompt:best-crm). This distinguishes it from sibling tools like parse_get_brand and parse_get_prompt, which are more specific.
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 term 'compatibility alias' implies it is a generic fallback for older callers, but the description does not explicitly state when to use this tool versus parse_get_brand, parse_get_prompt, or search. It provides no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_get_brandGet brand AI visibility briefAFetch 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 declare readOnlyHint=true, which is consistent. The description adds context that the response is 'concise' and 'public', and lists expected fields. However, it does not disclose additional behavioral aspects like response format, pagination, or authentication requirements beyond 'public'. With annotations present, the added value is moderate but not rich.
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 action and resource. It is concise and every phrase adds value by listing the brief's contents, avoiding any fluff or redundancy.
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 parameter and no output schema, the description covers the return contents in reasonable detail (list of fields). It lacks explicit guidance on input format and alternative usage scenarios, but for a simple tool the description is largely complete. The absence of output schema is mitigated by the content list.
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 only parameter 'slug_or_id' has no description in the schema. The tool description does not explain the parameter format or acceptable values, relying solely on the self-explanatory name. This is insufficient for low coverage; the description should compensate by explaining that the slug or ID identifies the brand.
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's action ('Fetch') and resource ('a concise public marketing brief for one brand'). It lists specific content areas (Parse score, strengths, weak spots, etc.), making its purpose distinct from siblings like parse_get_stats and parse_get_prompt.
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 usage: when you need a public brief for a single brand. It does not explicitly exclude alternatives or state when not to use, but the clear scope ('for one brand') and distinct content provide enough context. Sibling names suggest other specialized tools, though no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_get_promptGet AI prompt detailAFetch 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 readOnlyHint=true already indicates this is a safe read operation, and the description adds 'public organic' and 'exact AI-search question' as additional context. But it does not disclose other behavioral traits such as return format, error handling, or pagination, making this a modest contribution 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 sentence that front-loads the verb 'Fetch' and immediately states the resource and condition. It is concise with no wasted words, fitting the purpose perfectly.
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 single-parameter read tool, the description provides sufficient purpose but lacks details about the response content, limitations, or parameter semantics. With no output schema, a bit more explanation of what 'prompt detail' includes would improve 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 schema has 0% description coverage for the single 'slug' parameter. The description only repeats that the fetch is 'by slug' and does not explain what a slug is, its format, or any constraints. This gives minimal semantic value beyond the schema itself.
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 action ('Fetch one public organic prompt by slug') and a purpose ('inspect the exact AI-search question behind a result'). It clearly identifies the resource (prompt) and scope (public organic, by slug), but does not explicitly differentiate from sibling tools like parse_get_stats 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'), which tells when to use this tool. However, it does not mention when not to use it or suggest alternatives, so it falls slightly 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.
parse_get_statsSummarize Parse dataset scaleAExplain 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?
Annotations declare readOnlyHint=true, and the description does not contradict this. The description adds context about the content (scale and freshness) but discloses no additional behavioral traits such as output format, caching, or rate limits. For a simple read-only stats tool, this is adequate but not rich.
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, focused sentence that front-loads the primary action (Explain) and then lists the key content areas. It contains no extraneous information and is appropriately sized for a zero-parameter tool.
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 low complexity (no parameters, no output schema), the description sufficiently outlines the categories of information provided (tracked brands, organic prompts, citation observations). It could be more explicit about the response type, but in the context of sibling tools, this summary-level description is complete enough.
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 description does not need to explain parameter meanings. The baseline of 4 applies because the absence of parameters makes additional semantic explanation unnecessary.
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 identifies the resource (Parse index) and the specific aspects covered (scale, freshness, tracked brands, organic prompts, citations). The verb 'Explain' is somewhat vague but the subject matter clearly differentiates this from sibling lookup 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?
Usage context is implied: this provides a high-level summary of the Parse dataset, while siblings perform specific lookups. However, there is no explicit statement of when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_searchSearch Parse AI visibility dataAFind brands, organic AI prompts, citation sources, and market niches for marketer research. Use this first when the user names a brand, category, source, 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 provide readOnlyHint=true, and the description adds usage context but not much else. It does not describe return formats, how 'types' affects results, or whether results are aggregated, leaving the agent to infer behavior from the 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?
Two concise sentences with no fluff. The main purpose is front-loaded, and the usage guidance follows naturally. 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?
The description covers purpose and usage well, but given 0% schema description coverage and no output schema, it leaves out important details about the 'types' filter and 'limit.' It provides the essential starting point but is not fully complete for a parameterized search 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 0%, so the description must compensate. It only implicitly references 'query' via 'when the user names a brand, category, source, or AI visibility question.' The 'limit' and 'types' parameters are not mentioned at all, leaving them semantically undefined.
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 specific verbs and lists concrete resources: 'Find brands, organic AI prompts, citation sources, and market niches.' It also establishes its role as the primary entry point with 'Use this first,' clearly distinguishing it from siblings like general 'search' or specific 'get_brand' tools.
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 this first when the user names a brand, category, source, or AI visibility question' gives clear context on when to invoke the tool. However, it does not explicitly mention when not to use it or name alternative tools, keeping it one notch below a fully explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearchACompatibility 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?
The readOnlyHint annotation already declares this is a safe read operation, so the bar is lower. The description adds the alias relationship, which implies behavior matches parse_search, but it does not disclose any additional behavioral traits such as query syntax, result limits beyond schema constraints, or rate limits. This is adequate but not rich.
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 concise sentences with zero unnecessary words. It front-loads the core purpose (alias) and then gives the usage context. Every word earns its place, making it an model of concision.
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 a simple compatibility alias, so complexity is low. However, with no output schema and no parameter descriptions, the description is minimal. It points to parse_search for full behavior, which may be sufficient if the sibling documentation is available, but it is not self-contained. Given the sparse context, a score of 3 reflects that it is adequate but leaves the user to consult other tools.
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 only vaguely implies that 'query' is the search term and provides no explanation of the 'limit' parameter or any constraints. The description adds minimal value beyond the schema field names, which is insufficient for a tool with two undocumented parameters.
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 is a compatibility alias for parse_search, giving it a specific verb (alias) and pointing to a specific resource. However, it does not describe what parse_search itself does, so a reader unfamiliar with that sibling would not know the search behavior. It distinguishes itself from siblings by being the generic alias, but the purpose is somewhat deferred.
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 states when to use this tool: 'Use for clients that expect a generic search tool.' This implies that for other clients, parse_search should be used directly, providing clear usage context and an implicit alternative. This is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
