Skip to main content
Glama

Get brand AI visibility brief

parse_get_brand
Read-onlyIdempotent

Read any resolved brand's free public AI visibility evidence. Returns a compact summary by default; request a section for markets, topics, perception, rivals, questions, sources, history or family. Use a returned slug; preserve each metric's unit and date window. Numbers are shares, never counts: a rating's betterShare and worseShare, and perception's strength and weakness, are fractions of the answers comparing the brand on that attribute, with that sample's size as answers beside them; perception.words[].share is a fraction of the perception.described times AI used the brand's words. Weigh a share by its sample: under 20 it is weak evidence. For a local business, locations, area and markets[].place say where Parse's own read says it serves and how often AI mentions it in each place of its area. The data is the same public evidence shown on Parse's website, not private workspace tracking; absent measurements are not zero.

Input Schema

NameRequiredDescriptionDefault
brandYesThe brand's slug as parse_check_brand returned it, or its fetch id from parse_search, for example stripe-com or brand:stripe-com.
offsetNoUse the next offset returned by this tool for the same section.
sectionNosummary

Output Schema

NameRequiredDescriptionDefault
brandNo
foundYes
coverageNo
publicIndexNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / brand
      Added value: +{
      +  "description": "The brand's slug as parse_check_brand returned it, or its fetch id from parse_search, for example stripe-com or brand:stripe-com.",
      +  "type": "string"
      +}
    • removedInput schema / properties / slug_or_id
      Removed value: -{
      -  "description": "The brand's slug as parse_check_brand returned it, or its fetch id from parse_search, for example stripe-com or brand:stripe-com.",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "slug_or_id"
      -]New value: +[
      +  "brand"
      +]
  2. Changed3 schema fields changed
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Use the next offset returned by this tool for the same section.",
      +  "maximum": 10000,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / section
      Added value: +{
      +  "default": "summary",
      +  "enum": [
      +    "summary",
      +    "markets",
      +    "topics",
      +    "perception",
      +    "retrieval",
      +    "rivals",
      +    "questions",
      +    "sources",
      +    "history",
      +    "family"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "brand": {
      +      "type": "object"
      +    },
      +    "coverage": {
      +      "type": "object"
      +    },
      +    "found": {
      +      "type": "boolean"
      +    },
      +    "publicIndex": {
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "found"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / slug_or_id / description
      Previous value: -"The brand's slug as parse_search or parse_check_brand returned it, for example stripe-com."New value: +"The brand's slug as parse_check_brand returned it, or its fetch id from parse_search, for example stripe-com or brand:stripe-com."
  4. Changed1 schema field changed
    • addedInput schema / properties / slug_or_id / description
      Added value: +"The brand's slug as parse_search or parse_check_brand returned it, for example stripe-com."
  5. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Although annotations already cover read-only/idempotent/non-destructive, the description adds substantial behavioral context the annotations cannot: numbers are shares not counts, each share has an `answers` sample beside it, shares under 20 answers are weak evidence, and absent measurements are not zero. That last point is exactly the interpretive guardrail an agent needs to avoid reporting missing data as zero.

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

Conciseness3/5

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

The opening clause is well front-loaded, but the remainder is a dense semicolon-chained block mixing metric semantics, sample-size thresholds, local-business fields and data-provenance caveats. Most sentences earn their place, yet the lack of grouping makes the guidance harder to scan than it needs to be.

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

Completeness4/5

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

Given an output schema exists, the definition wisely spends its words on interpretation rather than return shape, covering share-vs-count semantics, sample weighting and local-business location fields. What remains thin is the unexplained 'retrieval' section and how paging terminates, but overall it is sufficient to call and interpret 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 brand parameter and offset are already documented in the schema, but the description explains what the section enum actually yields by naming the available views. Minor gap: it lists 'markets, topics, perception, rivals, questions, sources, history or family' while the enum also contains 'retrieval' and 'summary', leaving 'retrieval' unexplained in either place.

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?

Opens with a specific verb and resource — 'Read any resolved brand's free public AI visibility evidence' — and immediately states the default/section-return behavior. It also distinguishes itself from the workspace-tracking siblings by declaring the data is 'the same public evidence shown on Parse's website, not private workspace tracking.'

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

Usage Guidelines4/5

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

Tells the agent to 'use a returned slug' and points at parse_check_brand and parse_search as the sources for that slug, which is the key precondition. It does not explicitly say when to prefer this over siblings like parse_evidence or parse_track_brand, so it stops short of full alternative routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources