Request a Brand Discovery Record: the human-approved facts AI cites. One tool, then a person.
Scored across 1 tool
There is only one tool, so there is no possibility of confusing it with another. The tool's purpose as a request action is clearly described, removing any ambiguity.
With a single tool, naming consistency is trivially maintained. The name 'request_record' follows a clear verb_noun snake_case pattern that matches the action it performs.
The tool count is one, which is below the typical 3-15 range, but it is reasonable for a narrowly scoped public endpoint that intentionally delegates broader work to humans. The single tool is functional and purposeful.
The server's stated domain is to request a Brand Discovery Record, and this tool fully covers that action. It includes validation and versioning, and the description clarifies that publishing and measurement are intentionally handled outside the tool surface, so there are no obvious missing operations within the public scope.
Request a Brand Discovery Record — the human-approved source of truth a brand provides to AI assistants and agents, maintained by Mirror. A Record is a machine-readable reference page, hosted by Mirror, stating a brand's verified facts with schema.org structured data and citations, and linking to the brand's own site as the canonical source. It is what a brand PUBLISHES so AI can find, read and cite it: Mirror measures, the Record responds. This is the one public tool of the Mirror switchboard; the measurement itself (a full Brand Reflection) is delivered by a person on request. IMPORTANT — this tool creates a REQUEST, not a Record. Nothing is published by calling it. Automated validation (Gate 1) runs immediately and its results are returned to you. Every Brand Discovery Record is reviewed by Daniels AI and approved by the organization it represents before publication. No autonomous process publishes a brand's machine-readable truth. Fill the fields below with verified, citable facts only. The Record specification is versioned; this tool reports the version it validated against.
| Name | Required | Description | Default |
|---|---|---|---|
| social | No | Official profile URLs. | |
| address | No | {street, city, region, postal, country} | |
| history | No | Founding and lineage, factual. | |
| tagline | Yes | One plain line: what it is and where. | |
| overview | No | Short factual prose — what the brand is. | |
| citations | Yes | At least 3 authoritative sources from 3 DIFFERENT domains. | |
| brand_name | Yes | Exact public name of the brand. | |
| phone_e164 | No | E.164 format, e.g. +1-802-760-4653 | |
| description | Yes | 1-2 factual sentences, ~160 characters. No marketing claims. | |
| positioning | No | The most clarifying fact: category, who it serves, and what it is NOT. | |
| recognition | No | Awards or coverage, each traceable to a citation. | |
| schema_type | Yes | schema.org @type — e.g. GolfCourse, Restaurant, LodgingBusiness, Organization, LocalBusiness. | |
| official_url | Yes | The brand's OWN official website (canonical). Must be the brand's domain — never Mirror's. | |
| relationship | No | Who is asking, and on whose behalf. Only a request from someone representing the brand can become an authorized Record. | |
| founding_year | No | Year established (YYYY). | |
| public_access | No | Is it open to the public? The confusion-killer field. | |
| differentiator | No | The notable, verifiable thing. | |
| requester_note | No | Why this request is being made. | |
| requester_contact | No | Email for Gate 2 follow-up. Without it a Record cannot be authorized. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only generic annotations available, the description carries the full behavioral burden and does so well. It discloses that nothing is published, that Gate 1 validation runs immediately with results returned, that human approval is required, and that no autonomous process publishes a Record. This goes well beyond the annotation hints and does not contradict 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?
The key caveat about creating a request rather than a Record is front-loaded, which is good. However, the description is verbose: the slogan line 'Mirror measures, the Record responds' adds little functional value, and 'No autonomous process publishes...' largely restates the earlier human-review point. Not every sentence earns its place.
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 that there is no output schema and the tool has 19 parameters, the description provides a surprisingly complete workflow picture: request creation, immediate Gate 1 validation, returned results, human review, organizational approval, and version reporting. It does not describe the exact response structure, but for a request-submission tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed field-level descriptions such as 'At least 3 authoritative sources from 3 DIFFERENT domains' and 'E.164 format, e.g. +1-802-760-4653.' The tool description adds only a general requirement to provide 'verified, citable facts only,' so the schema carries the parameter-documentation load and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it requests a Brand Discovery Record. It also draws a crucial distinction between creating a REQUEST and creating a Record, and differentiates itself from the human-delivered 'full Brand Reflection.' An agent can tell exactly what this tool does.
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?
There are no sibling tools, but the description gives clear operational context: this is the one public tool, calling it creates a request, Gate 1 validation runs immediately, and results are returned. It does not explicitly state when not to use it, but the request-vs-record caveat and the human-delivered measurement boundary serve as practical guidance.
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.
reflectrequest_recordreflectSee and change how AI assistants describe your brand — AI representation management.
See how AI assistants answer about your brand
Measure how AI assistants cite your brand. Returns measured data and ready-to-apply fixes.
Query the AI Brand Directory. Audit brand visibility in ChatGPT, Claude, and Gemini.
Add one secure layer between your agents and this server.
