Request a Brand Discovery Record: the human-approved facts AI cites. One tool, then a person.
Scored across 1 tool
With only one tool, there is no possibility of misselection or overlap; its purpose (submitting a Brand Discovery Record request) is unambiguous and clearly distinct from the human-delivered measurement service.
The single tool uses a clean snake_case verb_noun pattern (request_record) that reads predictably; there is no competing convention to clash with it.
A one-tool surface is borderline thin; the description frames it as intentionally 'the one public tool of the Mirror switchboard,' which is defensible, but an agent has no companion operations to work with.
Submission is covered, but the Record lifecycle has notable gaps: no way to check request/approval status, retrieve or list published Records, or amend a submitted request, leaving agents at a dead end after the initial call.
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 (Signal Input) 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 | No | Optional. Any authoritative sources you already have, ideally 3 from 3 different domains — [{title, publisher, url}]. Supply what exists; Daniels sources citations as part of the engagement, so having none is not a barrier. | |
| 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 | No | Optional. schema.org @type — e.g. GolfCourse, Restaurant, LodgingBusiness, Organization. Omit if unsure; Daniels sets the type at Signal Review. | |
| official_url | Yes | The brand's OWN official website (canonical). Must be the brand's domain — never Mirror's. | |
| relationship | Yes | REQUIRED. Who is asking, and on whose behalf. Signal Input fails without it. Only a request from someone representing the brand can become an authorized Record. If you are trying this tool out, say "testing" — it is filed as a test, you still get the full Signal Input validation, and it never enters the review queue. | |
| 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 | REQUIRED. A working email for Signal Review and Signal Approval follow-up. Example/reserved domains (example.com, .test, .invalid) fail Signal Input. Without it a Record cannot be authorized. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the annotations, the description discloses that validation ("Signal Input") runs immediately, that results are returned synchronously, that every Record is human-reviewed and org-approved before publication, and that the spec is versioned and reported back. This is rich, accurate behavioral context that is consistent with readOnlyHint=false/destructiveHint=false. It stops short of describing what the validation response actually contains, which matters given there is no output schema.
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 roughly 3-4x longer than needed and includes promotional framing that does not help invocation ("Mirror measures, the Record responds", the multi-sentence definition of a Record page). The load-bearing sentence about creating a request rather than a Record is buried mid-paragraph rather than front-loaded, though the caps emphasis does help it stand out.
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 19-parameter, nested-object tool with no output schema and no siblings, the description covers the write semantics, the human-approval workflow, and the fact that synchronous validation results come back. The remaining gap is that it never characterizes the returned validation output, which the agent must interpret without an output schema.
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%, so the baseline is 3. The description adds only general guidance ("Fill the fields below with verified, citable facts only") and the versioning note; it does not prioritize the 19 fields or clarify the nested structures. The schema is doing essentially all of the parameter work.
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 eventually states a specific verb+resource and, crucially, disambiguates the artifact from the action: "this tool creates a REQUEST, not a Record. Nothing is published by calling it." That distinction is exactly what an agent needs. However, the first several sentences define what a Record *is* rather than what the tool does, so the actual purpose is delayed and muddied by surrounding prose.
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?
It notes this is "the one public tool of the Mirror switchboard" and that the measurement itself is delivered by a person on request, implying what this tool is not for. It also tells the agent to fill fields with "verified, citable facts only." But there is no explicit when-to-use/when-not-to-use framing or prerequisites beyond that; usage must be inferred.
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.
request_record3 fields changedInput schema / properties / citations / descriptionPrevious value: -"At least 3 authoritative sources from 3 DIFFERENT domains."New value: +"Optional. Any authoritative sources you already have, ideally 3 from 3 different domains — [{title, publisher, url}]. Supply what exists; Daniels sources citations as part of the engagement, so having none is not a barrier."Input schema / properties / schema_type / descriptionPrevious value: -"schema.org @type — e.g. GolfCourse, Restaurant, LodgingBusiness, Organization, LocalBusiness."New value: +"Optional. schema.org @type — e.g. GolfCourse, Restaurant, LodgingBusiness, Organization. Omit if unsure; Daniels sets the type at Signal Review."Input schema / requiredPrevious value: -[
- "brand_name",
- "official_url",
- "tagline",
- "description",
- "schema_type",
- "citations",
- "relationship",
- "requester_contact"
-]New value: +[
+ "brand_name",
+ "official_url",
+ "tagline",
+ "description",
+ "relationship"
+]request_record2 fields changedInput schema / properties / relationship / descriptionPrevious value: -"REQUIRED. Who is asking, and on whose behalf. Gate 1 fails without it. Only a request from someone representing the brand can become an authorized Record. If you are trying this tool out, say \"testing\" — it is filed as a test, you still get the full Gate 1 validation, and it never enters the review queue."New value: +"REQUIRED. Who is asking, and on whose behalf. Signal Input fails without it. Only a request from someone representing the brand can become an authorized Record. If you are trying this tool out, say \"testing\" — it is filed as a test, you still get the full Signal Input validation, and it never enters the review queue."Input schema / properties / requester_contact / descriptionPrevious value: -"REQUIRED. A working email for Gate 2 follow-up. Example/reserved domains (example.com, .test, .invalid) fail Gate 1. Without it a Record cannot be authorized."New value: +"REQUIRED. A working email for Signal Review and Signal Approval follow-up. Example/reserved domains (example.com, .test, .invalid) fail Signal Input. Without it a Record cannot be authorized."request_record4 fields changedInput schema / properties / relationship / descriptionPrevious value: -"Who is asking, and on whose behalf. Only a request from someone representing the brand can become an authorized Record."New value: +"REQUIRED. Who is asking, and on whose behalf. Gate 1 fails without it. Only a request from someone representing the brand can become an authorized Record. If you are trying this tool out, say \"testing\" — it is filed as a test, you still get the full Gate 1 validation, and it never enters the review queue."Input schema / properties / relationship / enumPrevious value: -[
- "represents_brand",
- "third_party",
- "testing",
- "other"
-]New value: +[
+ "represents_brand",
+ "agent_for_brand",
+ "third_party",
+ "testing",
+ "other"
+]Input schema / properties / requester_contact / descriptionPrevious value: -"Email for Gate 2 follow-up. Without it a Record cannot be authorized."New value: +"REQUIRED. A working email for Gate 2 follow-up. Example/reserved domains (example.com, .test, .invalid) fail Gate 1. Without it a Record cannot be authorized."Input schema / requiredPrevious value: -[
- "brand_name",
- "official_url",
- "tagline",
- "description",
- "schema_type",
- "citations"
-]New value: +[
+ "brand_name",
+ "official_url",
+ "tagline",
+ "description",
+ "schema_type",
+ "citations",
+ "relationship",
+ "requester_contact"
+]reflectrequest_recordreflectSee and change how AI assistants describe your brand — AI representation management.
See 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.
Add one secure layer between your agents and this server.
