Open AI Visibility Index for SaaS and AI tools. Weekly share-of-answer measurements for 20 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.
Scored across 5 tools
Each tool has a clearly distinct purpose: single-brand current visibility, per-brand history, methodology, full current index, and slug lookup. The descriptions explicitly cross-reference when to use each tool and when not to, eliminating ambiguity.
All tool names follow a consistent verb_noun snake_case pattern: get_brand_visibility, get_history, get_methodology, get_visibility_index, and list_tracked_brands. The mix of get_ and list_ is conventional and predictable.
Five tools is well-scoped for a niche data index. Each tool earns its place: current single brand, historical series, methodology, full index, and lookup table. No redundancy or unnecessary tools.
The domain is well covered: lookup, current single-brand data, full current index, historical trends, and methodology. The only minor gap is the absence of a past full-index snapshot in one call (get_history requires per-brand calls), but this is a workable limitation rather than a dead end.
One brand's standing in the current DABYTE 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 SaaS & AI tools 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 dabyte.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?
Beyond annotations, the description discloses important behaviors: re-measured weekly, same call returns same figures until next release; unknown slug error names every valid slug; absence from index vs measured zero; and data licensing/citation requirements. This goes well beyond readOnlyHint and idempotentHint.
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 average but every sentence adds distinct value: purpose, alternatives, error handling, data meaning, scope, refresh cadence, and licensing. It is front-loaded with the core purpose, and the structure makes it easy to parse, though slightly dense.
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 an output schema present, the description doesn't need to detail return fields, but it still mentions them. It covers error recovery, absence vs zero distinction, measurement frequency, alternative tools, and licensing requirements. No meaningful gaps remain for an agent to use this 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 input schema already fully documents the slug parameter with pattern and example. The description adds practical value by clarifying 'Takes a slug, not a display name' and directing users to call list_tracked_brands or read from get_visibility_index if unsure, which helps correct usage.
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: 'One brand's standing in the current DABYTE release' with specific fields like share of answer, rank, quadrant, and panel prompts. It explicitly differentiates from siblings by directing users to get_visibility_index for the whole field and get_history for trends over time.
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: 'Use this when a specific brand is named.' It also names alternatives and preconditions: 'call list_tracked_brands first if you are unsure' and 'For the field as a whole use get_visibility_index; for this brand over time, get_history.' This is model usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every DABYTE 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 dabyte.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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds crucial behavioral context beyond annotations: the panel version freeze and denominator change, the three-run measurement per engine since panel v3, the weekly refresh cycle, and the lack of auth/rate limits. It also clarifies data licensing and attribution requirements.
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 dense but every sentence earns its place: it leads with the core definition, then usage guidance, then critical interpretative caveats, then update frequency and licensing. No redundant or filler content; it is efficiently structured with distinct logical segments.
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 zero parameters, rich annotations, and an output schema, the description covers everything needed: what data is returned, how to interpret it (panel version boundaries, noise thresholds), how often it updates, and access requirements. It even tells users not to report step movements as gains/losses, which is essential operational guidance.
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 schema coverage is trivially 100%. The description adds no parameter semantics (there are none to add) but provides valuable context about the output's scope and interpretation, which is the only meaningful semantic content for this no-input tool. Baseline for zero parameters is 4.
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 what the tool does: it returns every DABYTE release ever published, as a series per brand, with share of answer, date, and panel version. It explicitly contrasts with sibling tools: 'For the current release alone use get_visibility_index' and 'Call get_methodology for the exact step size,' distinguishing it from alternatives.
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 this for any question about change — is a brand rising, when did it enter the index, how volatile is the category') and provides clear exclusions: comparability is invalid across panel versions, and small moves within noise should not be reported. It also names alternative tools for specific use cases (get_methodology, get_visibility_index).
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://dabyte.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 dabyte.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 mark this as read-only, idempotent, and non-destructive, but the description adds materially: returns rules not figures, no brand names, panel frozen between releases, recomputable archive, weekly re-measurement, CC BY 4.0, no auth/rate limits, and citation requirement. This goes well beyond the structured 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?
Well-structured and front-loaded: first paragraph states the core purpose, second gives usage triggers, third scopes output and alternatives, fourth covers operational details (cadence, licensing). Every sentence adds distinct value 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?
For a zero-input methodology tool with an output schema and strong annotations, this description is complete. It explains the conceptual return type, distinguishes from data tools, gives sourcing/reproducibility and attribution context, and notes the weekly refresh behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so input schema completely covers the interface and there is nothing for the description to add beyond the fact that no input is needed. Per the zero-parameter baseline this earns a 4.
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 'The rules behind every figure this server returns' and enumerates exactly what methodology covers (prompt panel, engines, scoring, rounding, resolution, editorial firewall). It explicitly differentiates itself from sibling tools by saying 'For figures use get_visibility_index or get_brand_visibility; for the series, use get_history.'
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?
Gives concrete triggers: call before quoting a number, before comparing releases, or when the user asks how measurement was made. It even states it is the only tool that explains meaningful differences, and points to alternatives for figures/series.
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 SaaS & AI tools 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 20 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 SaaS & AI tools only; the sibling index at dablock.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 dabyte.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 mark read-only, idempotent, and non-destructive; the description adds valuable context: weekly re-measurement, stable results until the next release, ~8 KB response size, no auth/rate limits, CC BY 4.0 licensing, and citation requirements. This goes well beyond the structured 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?
Although lengthy, every sentence earns its place: purpose first, followed by usage, exclusions, cadence, and licensing. The front-loaded structure makes the core function immediately clear, and no information is redundant.
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 an output schema exists, the description still covers field-level use cases, sibling routing, output size, update frequency, data license, and citation obligations. It is fully complete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the empty schema needs no elaboration—baseline is 4. The description still adds useful dataset semantics by defining 'share of answer' and clarifying the scope of tracked brands, which helps the agent understand what the tool returns.
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 opening sentence states the tool delivers the whole current release with every tracked brand, rank, share of answer, commercial intent, and quadrant. It clearly distinguishes itself from siblings by explicitly naming get_brand_visibility, get_history, and the external index for other niches.
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 'Use this when' conditions (field-level questions) and a 'Do NOT use it' section naming exact alternative tools and non-audit scope. This is ideal guidance for an agent choosing among siblings.
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 DABYTE 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 SaaS & AI tools only; the sibling index at dablock.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 dabyte.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 adds key behavioral context: 'Re-measured weekly, so the same call returns the same figures until the next release' and 'Absence here means the brand is not measured, not that it scores zero.' It also discloses scope and licensing ('Covers SaaS & AI tools only... Data is CC BY 4.0... no key, no account, no rate limit'), enriching the agent's understanding 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 is front-loaded with the core purpose, then flows logically into usage examples, exclusions, data freshness, and licensing. Every sentence provides unique value, and the structure is tight despite covering multiple aspects. It is long but not wasteful.
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-only tool with an output schema available, the description is exceptionally complete. It covers what the tool returns, when to use it, when not to, data freshness, scope boundaries, and access constraints, leaving no ambiguity for an agent.
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 cannot add parameter-level meaning. The empty schema is fully covered, and the description appropriately focuses on output semantics (names and slugs). With 0 params, the baseline is 4, and the description meets that by clarifying the output scope.
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 lists the names and slugs of every brand in the DABYTE index, explicitly calling it a lookup table with no scores or ranks. It also distinguishes itself from siblings by mentioning get_brand_visibility and get_visibility_index, so the verb+resource is specific and differentiated.
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: '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.' It also gives a clear when-not-to-use rule: 'Do NOT use it when you want figures — get_visibility_index returns the same brands with their full measurements in a single call.' This fully covers usage vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_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_brands
Add one secure layer between your agents and this server.
