exposure-audit

run_exposure_audit

Run a free competitive-exposure / AI-visibility audit for a business domain.

No account or API key needed. Pass a bare registrable domain (e.g. "acme.com"), not a full URL. A first-time domain starts a background run and this returns a "started" message — call the tool again with the same domain in about 2-3 minutes to fetch the result. Repeat domains within the cache window return instantly. This is a strictly rate-limited free tool, not a general-purpose research API — see the response text for status and the free-usage cap. A completed result ends with a link to view the same result on dozier.io (and run a free audit there).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries full responsibility. It discloses that no account/API key is needed, the background-run behavior, rate limiting, free-usage cap, and that response text contains status and a link to view results. This is thorough and honest about the tool's limitations.

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

Conciseness4/5

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

The description is a single dense paragraph covering purpose, input format, async behavior, rate limits, and output link. No sentence is wasted, but it could be slightly more scannable with brief line breaks; still, it is concise and front-loaded with the purpose.

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

Completeness5/5

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

Given the tool's complexity (async, cache, rate limits) and the presence of an output schema, the description covers all essential usage aspects needed to call it correctly: input constraints, timing for results, repeat behavior, and where to find status/cap info. The output format is left to the schema, which is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must clarify the parameter. It explicitly states the accepted format ('bare registrable domain... not a full URL') and gives an example ('acme.com'), adding significant meaning beyond the schema's bare 'domain' field.

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?

The description states a specific verb ('Run') and resource ('free competitive-exposure / AI-visibility audit') with a clear scope ('for a business domain'). It immediately distinguishes the tool's function and is not a tautology, earning full marks.

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

Usage Guidelines5/5

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

Provides explicit input requirements ('bare registrable domain... not a full URL'), asynchronous behavior (first-time returns 'started', repeat after 2-3 minutes to fetch result), and cache semantics. It also mentions rate limits and that it's not a general-purpose API, giving clear exclusions.

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

All exposure-audit tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools. The tool's purpose is clearly defined and unambiguous.

Naming Consistency5/5

The single tool name follows a clear verb_noun pattern (run_exposure_audit), which is consistent and predictable. No conflicting conventions exist.

Tool Count3/5

With only one tool, the server feels minimal and borderline thin. However, the tool serves a narrow, specific purpose (running an exposure audit), so the count, while low, is not unreasonable for the scope.

Completeness4/5

The single tool covers the core workflow (start and retrieve an audit) with no obvious dead ends. Minor gaps exist—such as lacking a separate list or history tool—but agents can work around them by re-calling the tool with the same domain.

Resources

Need Help?