DABLOCK AI Visibility Index

by ai.dablock

Overview Discussions Admin

Server Details

Measured share of answer for 24 crypto and Web3 brands. An open dataset, not an audit of your site.

Ownership verified

Status: Healthy
Last Tested: 2026-09-15 11:55
Transport: Streamable HTTP
URL
Repository: creanlab/ai-visibility-index
GitHub Stars: 0
Server Listing: ai-visibility-index

TDQS

A4.9/5.0

Scored 2026-09-09 18:36 across 5 tools

Disambiguation5/5

Each tool targets a distinct question: current field-level figures, current single-brand figures, history over time, methodology, and slug lookup. The descriptions explicitly cross-reference the other tools and state when not to use each one, so an agent should rarely misfire.

Naming Consistency5/5

All tool names follow a clear verb_noun snake_case pattern: get_brand_visibility, get_history, get_methodology, get_visibility_index, list_tracked_brands. The single list_ verb is conventional for a lookup operation and does not break the pattern.

Tool Count5/5

Five tools map cleanly to the natural operations on this read-only dataset: current index, one brand, history, methodology, and slug lookup. The server is tightly scoped and no tool feels redundant.

Completeness5/5

For a read-only measurement index, the surface is complete: agents can resolve slugs, query current figures at field or brand level, trace history, and understand methodology before citing numbers. There are no obvious dead ends or missing operations.

Available Tools

5 tools

get_brand_visibilityLook up one brandA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Brand slug, lowercase with hyphens — 'slack', 'coinbase', 'monday-com'. Not the display name.

Output Schema

ParametersJSON Schema

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.

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

get_historyFull measurement time seriesA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`series`	No	Per brand slug, the share of answer at each release.
`measurements`	No

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

get_methodologyHow the index is measuredA

Read-onlyIdempotent

Inspect

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/.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

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.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent hints, the description discloses key behavioral traits: weekly re-measurement with stable figures between releases, that it returns no brand names, the frozen public panel, and no auth/rate limits. These add significant context not available from annotations alone, with no contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with clear paragraphs: purpose, usage, output type, and data licensing/update cadence. It is somewhat longer than strictly necessary, but every sentence contributes meaningful information. The front-loaded purpose and usage guidance improve navigability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is highly complete given the tool's complexity and empty schema. It covers what the tool does, when to call it, how to interpret the results, the update frequency, licensing, and attribution requirements. The presence of an output schema reduces the need to detail return values, and this description fully addresses the operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there are no parameter semantics to clarify. The description compensates by explaining what the response contains (rules, not figures), which aligns with the schema's empty properties. A baseline of 4 is appropriate for a no-parameter tool with thorough output description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's function: 'The rules behind every figure this server returns,' and differentiates it from sibling tools by clarifying it 'returns rules, not figures' while naming get_visibility_index, get_brand_visibility, and get_history for figures and series. This is a specific verb+resource with clear scope and sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use instructions: '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 names alternative tools for figures and series, providing clear usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_visibility_indexDABLOCK AI Visibility Index — full tableA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

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.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, but the description adds critical context: the data is re-measured weekly so the same call returns the same figures until the next release, it is free with no key/account/rate limit, and CC BY 4.0 licensing. It also notes the response size (~8 KB for 24 brands). This goes well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is about 150 words but every sentence earns its place: it defines the output, gives usage guidance, lists exclusions with alternative tools, states data freshness, and notes licensing/attribution. It is front-loaded with the core purpose and contains no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has zero parameters and an output schema, the description covers all necessary context: what it does, when to use it, alternatives, data freshness, licensing, and the fact that it is not a website audit. It also mentions the sibling index at dabyte.ai for the other niche. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters and the schema is empty, so per the rubric the baseline is 4. The description does not need to explain parameters, and it appropriately confirms the tool requires no input. It additionally mentions the dataset scope (24 brands, 8 KB), which gives context about what the call returns without needing parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'The whole current release in one call' and enumerates exactly what is included: every tracked brand in crypto/Web3 with rank, share of answer, commercial intent, and quadrant. This is a specific verb+resource+scope, and it explicitly contrasts with get_brand_visibility and get_history, which distinguishes it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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 ('when the question is about the field — who leads, who is absent, how the category looks') and when not to, naming exact alternatives: 'get_brand_visibility is the direct answer' for a single brand, 'get_history holds the series' for trends, and clarifies it is not a website audit. This is complete guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tracked_brandsList tracked brands and slugsA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`brands`	Yes

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesAug 5, 2026

Changedget_brand_visibility3 fields changed

changedInput schema / properties / slug / description

Previous value: -"Brand slug, e.g. 'slack' or 'coinbase'"New value: +"Brand slug, lowercase with hyphens — 'slack', 'coinbase', 'monday-com'. Not the display name."

addedInput schema / properties / slug / pattern
```
Added value: +"^[a-z0-9-]{1,80}$"
```

changedOutput 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"
+}

Changedget_history1 field changed

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"
+}

Changedget_methodology1 field changed

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"
+}

Changedget_visibility_index1 field changed

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"
+}

Changedlist_tracked_brands1 field changed

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"
+}

5 tool updatesAug 5, 2026
- First observedget_brand_visibility
- First observedget_history
- First observedget_methodology
- First observedget_visibility_index
- First observedlist_tracked_brands

Related MCP Connectors

DABYTE AI Visibility Index A
ai.dabyte
Measured share of answer for 20 SaaS brands. An open dataset, not an audit of your site.
Marketing Open Data Research & Data
51
promvia
app.promvia
AI visibility: is your brand cited by ChatGPT, Perplexity, Gemini? SoV, GEO score, AI traffic.
Marketing
1
AIsa AI Visibility AOAuth
one.aisa
How a brand shows up in ChatGPT, Claude, Gemini and Perplexity answers.
Marketing Search
281
Ninar AI A
ai.ninar
Audit your brand's visibility across ChatGPT, Gemini, Claude, Perplexity + 6 more engines.
Monitoring Search Marketing
52

Related MCP Servers

ai-visibility-mcp
Marketing Search Monitoring
sharozdawa
A
license
A
quality
C
maintenance
Track brand visibility across ChatGPT, Perplexity, Claude, and Gemini.
Updated 6 months ago (2026-03-22 09:30 UTC)
6
95 npm
9
MIT
agentaeo-mcp-server
Marketing Search Content Management Systems
agentaeo
A
license
A
quality
D
maintenance
Audit your brand's visibility across ChatGPT, Perplexity, Claude, and Google AI - get citation rates, AEO health scores, content gap analysis, and a 9-page content suite to rank in AI-generated answers.
Updated 4 months ago (2026-05-05 18:29 UTC)
5
54 npm
MIT
vantage-mcp
Marketing Search
vantagemcp
A
license
A
quality
A
maintenance
Checks whether ChatGPT, Perplexity, and Gemini cite your brand for a given keyword, and who's winning the citation battle for it instead.
Updated 2 days ago (2026-09-13 10:53 UTC)
4
6
MIT
Citare
Search Marketing AI & Machine Learning
ravirdp
A
license
Not graded
quality
D
maintenance
AI search intelligence + Ahrefs-class SEO suite as 59 MCP tools. Track your brand across ChatGPT, Google AI Overview, Gemini, Claude, and Perplexity with persona-anchored Brand Radar dispatches.
Updated 4 months ago (2026-05-26 08:26 UTC)
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources