Open AI Visibility Index for crypto and Web3. Weekly share-of-answer measurements for 24 tracked brands across ChatGPT, Perplexity and Gemini, from a frozen versioned prompt panel. Five read-only tools: full index, per-brand lookup, brand list, complete measurement history and methodology. No auth, no API key. Data is CC BY 4.0 with a permanent archive of every weekly snapshot, so any figure can be verified independently.
One brand's standing in the current DABLOCK release: share of answer per engine, rank, quadrant, how many panel prompts name it, and which ones.
Use this when a specific brand is named. Takes a slug, not a display name — call list_tracked_brands first if you are unsure, or read the slug from get_visibility_index.
An unknown slug is not a failure to hide: the error names every valid slug, so a second attempt can succeed. A brand absent from the index has not been measured at all, which is different from a measured zero. Only crypto/Web3 brands are tracked. For the field as a whole use get_visibility_index; for this brand over time, get_history.
Re-measured weekly, so the same call returns the same figures until the next release. Data is CC BY 4.0 and free: no key, no account, no rate limit — cite the release date and dablock.ai when quoting a number.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Brand slug, lowercase with hyphens — 'slack', 'coinbase', 'monday-com'. Not the display name. |
| Name | Required | Description |
|---|---|---|
| rank | Yes | Position in this release, 1 = most named. |
| slug | Yes | Identifier used by get_brand_visibility. |
| brand | Yes | Brand name as published. |
| engines | No | Engines measured in this release. |
| prompts | No | Panel prompts in which the brand is named. |
| quadrant | No | Position on visibility against commercial intent. |
| is_client | No | Whether the brand is a client of the publisher. Placement cannot be bought; this flag makes that checkable. |
| per_engine | No | Share of answer per engine, same scale. |
| measured_at | Yes | Date of this release, ISO 8601. |
| niche_title | No | |
| panel_version | No | Prompt panel version. Figures from different versions are not comparable. |
| visibility_score | Yes | Share of answer, percent of panel prompts naming the brand. |
| commercial_intent | No | How commercially loaded the brand's category demand is. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint, idempotentHint, etc.) by disclosing error behavior ('the error names every valid slug'), semantic distinction ('absent from the index... different from a measured zero'), scope ('Only crypto/Web3 brands are tracked'), refresh cadence ('Re-measured weekly'), and licensing/citation requirements. This adds substantive contextual value.
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?
Despite being a single dense paragraph, every sentence earns its place: purpose, usage, error handling, distinctions, scope, refresh, and licensing. It is front-loaded with the core definition, and no redundant or filler content exists.
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 one parameter and an output schema, the description provides complete context: what data is returned, how to interpret missing data, how to obtain valid inputs, when to use alternatives, and usage constraints (free, no key, attribution). This covers all necessary aspects for an agent to select and invoke the tool correctly.
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 already provides 100% parameter description for 'slug' including format and examples. The description reinforces this ('Takes a slug, not a display name') and adds a practical sourcing strategy (call list_tracked_brands or read from get_visibility_index), which enhances usability beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'One brand's standing in the current DABLOCK release' and enumerates concrete metrics (share of answer per engine, rank, quadrant, prompt mentions). It clearly distinguishes itself from siblings by stating 'Use this when a specific brand is named' and later directing to alternatives for other intents.
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?
Explicit when-to-use guidance: 'Use this when a specific brand is named.' It also provides when-not-to-use with named alternatives: 'For the field as a whole use get_visibility_index; for this brand over time, get_history.' Additionally, it instructs on prerequisites: 'call list_tracked_brands first if you are unsure, or read the slug from get_visibility_index.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every DABLOCK release ever published, as a series per brand: share of answer at each weekly measurement with the date and panel version it was taken under.
Use this for any question about change — is a brand rising, when did it enter the index, how volatile is the category.
Two limits decide whether an answer is honest. Figures are comparable only WITHIN a panel version: the panel is frozen between releases and a version change alters the denominator, so a difference across that boundary is not a trend. And small moves sit inside language-model noise: since panel v3 (2026-08-10) each prompt runs three times per engine per release and the figure is the share of runs; earlier releases ran each prompt once, so one mention on one engine was a whole scale step there. Either way a one-step movement should not be reported as a gain or a loss. Call get_methodology for the exact step size. For the current release alone use get_visibility_index.
Re-measured weekly, so the same call returns the same figures until the next release. Data is CC BY 4.0 and free: no key, no account, no rate limit — cite the release date and dablock.ai when quoting a number.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| series | No | Per brand slug, the share of answer at each release. |
| measurements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the annotations: figures are comparable only within a panel version, there is language-model noise for small moves, and the data is re-measured weekly so the same call returns the same figures until the next release. It also notes licensing and no-auth requirements, enriching the readOnly/idempotent hints.
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 front-loaded with the core purpose, followed by usage guidance, then detailed limitations and licensing. Every sentence is informative and contributes to the agent's understanding without 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?
The description is fully complete for a parameterless historical data tool. It covers purpose, usage context, interpretation caveats (panel version boundaries and noise), alternatives, update frequency, and licensing, making it self-sufficient for an agent to invoke correctly.
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 schema already covers everything. The description does not need to explain parameters; the baseline for 0 params is 4. The description adds no parameter info but that is entirely appropriate.
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 returns every DABLOCK release ever published as a per-brand time series with share of answer, date, and panel version. It also distinguishes itself from siblings by directing users to get_visibility_index for the current release and get_methodology for exact step sizes.
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 says 'Use this for any question about change' and provides exclusions: 'For the current release alone use get_visibility_index' and 'Call get_methodology for the exact step size.' This gives strong when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rules behind every figure this server returns: the exact prompt panel and its version, which engines were measured, how share of answer is scored and rounded, the resolution of the scale in percentage points, and the editorial firewall and ownership disclosure.
Call this before quoting a number as evidence, before comparing two releases, or whenever a user asks how the measurement was made or who publishes it. It is the only tool that tells you how much of a difference is meaningful, which is what stops a one-step wobble being reported as a movement.
It returns rules, not figures — no brand appears in the response. For figures use get_visibility_index or get_brand_visibility; for the series, get_history. The panel is public and frozen between releases, so every published number can be recomputed by a third party from the archive at https://dablock.ai/archive/.
Re-measured weekly, so the same call returns the same figures until the next release. Data is CC BY 4.0 and free: no key, no account, no rate limit — cite the release date and dablock.ai when quoting a number.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| engines | No | Engines measured in this release. |
| license | No | |
| scoring | No | How share of answer is computed. |
| publisher | No | |
| resolution | No | Percentage points one mention on one engine is worth. |
| measured_at | No | Date of this release, ISO 8601. |
| niche_title | No | |
| prompt_panel | No | The exact prompts, verbatim. |
| panel_version | No | Prompt panel version. Figures from different versions are not comparable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds significant behavioral context: the tool is re-measured weekly (content stable between releases), requires no key/account, has no rate limit, and returns rules rather than figures. These details go beyond the structured annotations and help the agent understand side effects, availability, and update semantics.
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 longer than the high-calibration example but is well-structured and front-loaded. Each sentence serves a purpose: purpose, when-to-use, alternatives, return type, stability, licensing, and citation requirement. Some minor redundancy (e.g., 'Re-measured weekly' and 'same call returns same figures') but overall economical.
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 has no parameters and a rich output schema, the description fully compensates by explaining what the response contains (rules, no brand), the underlying data source (public archive), update frequency (weekly), and usage constraints (CC BY 4.0, no rate limit). This is complete for an agent to decide when and how to invoke it.
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 empty schema is fully covered. Per the rubric, a baseline of 4 is appropriate. The description does not need to explain parameter semantics, but it does clarify the output semantics (rules vs figures), which is valuable.
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 function: it returns the methodology/rules behind every figure. It explicitly says 'It returns rules, not figures' and distinguishes itself as 'the only tool that tells you how much of a difference is meaningful,' setting it apart from sibling tools that return actual visibility figures.
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 explicit when-to-use guidance: 'Call this before quoting a number as evidence, before comparing two releases, or whenever a user asks how the measurement was made or who publishes it.' It also specifies alternatives: 'For figures use get_visibility_index or get_brand_visibility; for the series, get_history.' This is model examples of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The whole current release in one call: every tracked brand in crypto/Web3 with its rank, share of answer overall and per engine, commercial intent and quadrant. Share of answer is the percentage of a fixed panel of category buyer prompts in which an engine names the brand.
Use this when the question is about the field — who leads, who is absent, how the category looks. It is one response of roughly 8 KB for 24 brands, so prefer it over calling get_brand_visibility repeatedly.
Do NOT use it for one named brand (get_brand_visibility is the direct answer), for movement over time (get_history holds the series; a single release cannot show a trend), or to audit a website's own AI visibility — this is a measured dataset about third-party brands, not a site audit. Covers crypto/Web3 only; the sibling index at dabyte.ai covers the other niche.
Re-measured weekly, so the same call returns the same figures until the next release. Data is CC BY 4.0 and free: no key, no account, no rate limit — cite the release date and dablock.ai when quoting a number.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| engines | No | Engines measured in this release. |
| entries | Yes | |
| measured_at | Yes | Date of this release, ISO 8601. |
| niche_title | No | |
| panel_version | No | Prompt panel version. Figures from different versions are not comparable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds valuable behavioral context: 'Re-measured weekly, so the same call returns the same figures until the next release' (caching/refresh), and 'no key, no account, no rate limit' (auth and rate limits). It also clarifies licensing and citation requirements. This meaningfully supplements the annotations without contradicting them.
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?
Despite being longer than typical, every sentence carries substantive information: what the tool returns, the definition of 'share of answer', when to prefer it, explicit exclusions, coverage scope, refresh cadence, and licensing. It is front-loaded with the core purpose and then organized into use/avoid/data sections. Nothing is redundant or filler.
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 complete for this tool's complexity. It covers the dataset contents, the meaning of a key metric, usage conditions, limitations, scope, and update frequency. An output schema exists, so return-value details are handled there. Sibling context is provided via explicit mentions. There are no significant gaps for an agent to select and invoke the tool correctly.
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, and the schema is fully covered (trivially 100%). Per the rubric, 0 params gives a baseline of 4. The description adds no parameter-specific info because none exists, but it does mention the response size ('roughly 8 KB for 24 brands'), which is more behavioral than semantic. No deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'The whole current release in one call: every tracked brand in crypto/Web3 with its rank, share of answer overall and per engine, commercial intent and quadrant.' It explicitly distinguishes itself from siblings by naming get_brand_visibility and get_history as alternatives, and clarifies what it is not for (single brand, trends, site audit). This is a specific, well-differentiated purpose.
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 guidance is explicit and actionable. It states when to use it ('when the question is about the field — who leads, who is absent, how the category looks'), when not to use it ('Do NOT use it for one named brand... for movement over time... or to audit a website's own AI visibility'), and names the alternative tools. This goes beyond vague context and provides clear decision rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The names and slugs of every brand in the DABLOCK index — a lookup table, nothing else. No scores, no ranks.
Use it for two things: to turn a brand name into the slug get_brand_visibility needs, and to answer whether a brand is tracked at all.
Do NOT use it when you want figures — get_visibility_index returns the same brands with their full measurements in a single call, so calling this one first is a wasted round trip. Absence here means the brand is not measured, not that it scores zero. Covers crypto/Web3 only; the sibling index at dabyte.ai covers the other niche.
Re-measured weekly, so the same call returns the same figures until the next release. Data is CC BY 4.0 and free: no key, no account, no rate limit — cite the release date and dablock.ai when quoting a number.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| brands | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description clarifies that absence from the list means not measured rather than zero, states the weekly re-measurement cadence, and specifies licensing/attribution and lack of rate limits. These add meaningful behavioral context without contradicting annotations.
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 opens with a clear purpose sentence, then uses short labeled paragraphs for usage, exclusions, and data semantics. No filler; each sentence contributes distinct information (scope, absence semantics, refresh, licensing).
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 lookup tool, the description covers all necessary context: what the list contains, how to use it, what it deliberately omits, the interpretation of absence, coverage scope, update frequency, and usage terms. The output schema handles return details, so no further description is needed.
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 correctly omits parameter guidance. With no parameters, the baseline is 4; there is nothing for the description to add beyond what the empty schema already implies.
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 explicitly states 'The names and slugs of every brand in the DABLOCK index' with 'nothing else,' positioning it as a pure lookup table. It distinguishes from siblings by noting 'No scores, no ranks' and naming get_visibility_index as the alternative for measurements.
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?
Provides two concrete use cases ('turn a brand name into the slug get_brand_visibility needs' and 'answer whether a brand is tracked') and an explicit do-not-use ('Do NOT use it when you want figures') with the alternative named. Also notes niche coverage difference.
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. Dates show when Glama detected each change.
get_brand_visibility3 fields changedInput schema / properties / slug / descriptionPrevious value: -"Brand slug, e.g. 'slack' or 'coinbase'"New value: +"Brand slug, lowercase with hyphens — 'slack', 'coinbase', 'monday-com'. Not the display name."Input schema / properties / slug / patternAdded value: +"^[a-z0-9-]{1,80}$"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "brand": {
+ "description": "Brand name as published.",
+ "type": "string"
+ },
+ "commercial_intent": {
+ "description": "How commercially loaded the brand's category demand is.",
+ "type": "number"
+ },
+ "engines": {
+ "description": "Engines measured in this release.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "is_client": {
+ "description": "Whether the brand is a client of the publisher. Placement cannot be bought; this flag makes that checkable.",
+ "type": "boolean"
+ },
+ "measured_at": {
+ "description": "Date of this release, ISO 8601.",
+ "type": "string"
+ },
+ "niche_title": {
+ "type": "string"
+ },
+ "panel_version": {
+ "description": "Prompt panel version. Figures from different versions are not comparable.",
+ "type": "integer"
+ },
+ "per_engine": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Share of answer per engine, same scale.",
+ "type": "object"
+ },
+ "prompts": {
+ "description": "Panel prompts in which the brand is named.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "quadrant": {
+ "description": "Position on visibility against commercial intent.",
+ "type": "string"
+ },
+ "rank": {
+ "description": "Position in this release, 1 = most named.",
+ "type": "integer"
+ },
+ "slug": {
+ "description": "Identifier used by get_brand_visibility.",
+ "type": "string"
+ },
+ "visibility_score": {
+ "description": "Share of answer, percent of panel prompts naming the brand.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "brand",
+ "slug",
+ "rank",
+ "visibility_score",
+ "measured_at"
+ ],
+ "type": "object"
+}get_history1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "measurements": {
+ "items": {
+ "properties": {
+ "measured_at": {
+ "type": "string"
+ },
+ "panel_version": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "series": {
+ "additionalProperties": {
+ "type": "array"
+ },
+ "description": "Per brand slug, the share of answer at each release.",
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_methodology1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "engines": {
+ "description": "Engines measured in this release.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "license": {
+ "type": "string"
+ },
+ "measured_at": {
+ "description": "Date of this release, ISO 8601.",
+ "type": "string"
+ },
+ "niche_title": {
+ "type": "string"
+ },
+ "panel_version": {
+ "description": "Prompt panel version. Figures from different versions are not comparable.",
+ "type": "integer"
+ },
+ "prompt_panel": {
+ "description": "The exact prompts, verbatim.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "resolution": {
+ "description": "Percentage points one mention on one engine is worth.",
+ "type": "string"
+ },
+ "scoring": {
+ "description": "How share of answer is computed.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_visibility_index1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "engines": {
+ "description": "Engines measured in this release.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "entries": {
+ "items": {
+ "properties": {
+ "brand": {
+ "description": "Brand name as published.",
+ "type": "string"
+ },
+ "commercial_intent": {
+ "description": "How commercially loaded the brand's category demand is.",
+ "type": "number"
+ },
+ "is_client": {
+ "description": "Whether the brand is a client of the publisher. Placement cannot be bought; this flag makes that checkable.",
+ "type": "boolean"
+ },
+ "per_engine": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Share of answer per engine, same scale.",
+ "type": "object"
+ },
+ "quadrant": {
+ "description": "Position on visibility against commercial intent.",
+ "type": "string"
+ },
+ "rank": {
+ "description": "Position in this release, 1 = most named.",
+ "type": "integer"
+ },
+ "slug": {
+ "description": "Identifier used by get_brand_visibility.",
+ "type": "string"
+ },
+ "visibility_score": {
+ "description": "Share of answer, percent of panel prompts naming the brand.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "brand",
+ "slug",
+ "rank",
+ "visibility_score"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "measured_at": {
+ "description": "Date of this release, ISO 8601.",
+ "type": "string"
+ },
+ "niche_title": {
+ "type": "string"
+ },
+ "panel_version": {
+ "description": "Prompt panel version. Figures from different versions are not comparable.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "measured_at",
+ "entries"
+ ],
+ "type": "object"
+}list_tracked_brands1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "brands": {
+ "items": {
+ "properties": {
+ "brand": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "brand",
+ "slug"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "brands"
+ ],
+ "type": "object"
+}get_brand_visibilityget_historyget_methodologyget_visibility_indexlist_tracked_brandsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Add one secure layer between your agents and this server.
Each tool has a distinct purpose: one for a single brand's current standing, one for time series, one for methodology, one for the full index, and one for brand/slug lookup. The descriptions explicitly cross-reference when to use each, eliminating ambiguity.
All tools follow a consistent lowercase snake_case verb_noun pattern, with four 'get_*' and one 'list_*' tool. The naming is uniform and predictable, making it easy to infer what each tool does.
Five tools is an ideal size for this narrow, read-only domain—not too sparse, not bloated. Each tool covers a necessary aspect of accessing the DABLOCK dataset, and there is no redundancy.
The tool set provides complete coverage for the domain: retrieving the full snapshot, individual brand data, historical trends, methodology/rules, and a lookup table for slugs. No obvious missing operations exist for querying this dataset.