The Mirror System — AI Citability

Request a Brand Discovery Record

request_record

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 3, 2026

changedInput schema / properties / citations / description

Previous 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."

changedInput schema / properties / schema_type / description

Previous 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."

changedInput schema / required

Previous value: -[
-  "brand_name",
-  "official_url",
-  "tagline",
-  "description",
-  "schema_type",
-  "citations",
-  "relationship",
-  "requester_contact"
-]New value: +[
+  "brand_name",
+  "official_url",
+  "tagline",
+  "description",
+  "relationship"
+]

Changed2 schema fields changedSep 29, 2026

changedInput schema / properties / relationship / description

Previous 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."

changedInput schema / properties / requester_contact / description

Previous 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."

Changed4 schema fields changedSep 24, 2026

changedInput schema / properties / relationship / description

Previous 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."

changedInput schema / properties / relationship / enum

Previous value: -[
-  "represents_brand",
-  "third_party",
-  "testing",
-  "other"
-]New value: +[
+  "represents_brand",
+  "agent_for_brand",
+  "third_party",
+  "testing",
+  "other"
+]

changedInput schema / properties / requester_contact / description

Previous 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."

changedInput schema / required

Previous value: -[
-  "brand_name",
-  "official_url",
-  "tagline",
-  "description",
-  "schema_type",
-  "citations"
-]New value: +[
+  "brand_name",
+  "official_url",
+  "tagline",
+  "description",
+  "schema_type",
+  "citations",
+  "relationship",
+  "requester_contact"
+]

AddedSep 19, 2026

TDQS

A3.6/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

All The Mirror System — AI Citability tools Inspect

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.

Resources

Need Help?