AI-answer-engine visibility scans for local businesses, as agent tools
Scored across 9 tools
Each tool has a distinct purpose: documentation, examples, health, scan, report, stats, watch status, and skill listing/reading. There is no overlap; even the two skill tools are clearly separate (list vs read).
Most tools use the 'cited_' prefix, but the naming style is inconsistent: some are noun phrases (cited_api_docs, cited_health), some are verbs implied (cited_scan, cited_report), and two tools (read_skill, skills_list_tool) break the prefix pattern entirely. The mixed conventions are still readable but lack a uniform verb_noun structure.
Nine tools is well within the ideal range (3–15). Each tool covers a distinct function necessary for the server's purpose—scanning, reporting, monitoring, stats, and skill access—without redundancy or bloat.
The core workflows (scan → report, monitor status, get stats) are covered. Minor gaps exist: there is no tool to subscribe/unsubscribe to monitoring, and no way to list past scans, but these are not critical dead ends given the free-tier scope. Documentation and examples round out the surface.
Self-serve documentation for Cited — quickstart, MCP tools, REST endpoints, error shapes, and agent-operator policies, as markdown.
Args: topic: "quickstart" | "mcp" | "rest" | "errors" | "policies" | "all" (default "" == "all"). Unknown topics fall back to full docs.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explains the default topic behavior ('all') and the fallback for unknown topics, which is valuable. It does not explicitly state read-only status, but the nature of the tool implies it, and the description adds key behavioral traits beyond what the schema provides.
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 concise and well-structured, with the main purpose front-loaded and the argument specification following in a clean args block. Every sentence contributes necessary information without redundancy.
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?
The description is sufficient for a documentation retrieval tool. It explains what the tool does, the argument behavior, and the output format (markdown). Without an output schema, it could describe the return value more explicitly, but the 'as markdown' clause is adequate for the agent's needs.
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?
The schema provides no description for the 'topic' parameter, so the description fully compensates by enumerating valid values and explaining the default and fallback behavior. This is essential for correct invocation and provides substantial meaning beyond the schema.
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 clearly identifies the tool's function: providing self-serve documentation for Cited in markdown format, covering specific topics like quickstart, MCP, REST, errors, and policies. It distinguishes from sibling tools such as cited_examples and cited_health by specifying its exact scope.
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?
The description implies when to use the tool by listing the available topics, giving the agent clear context for selecting it based on the needed documentation. It does not explicitly mention alternatives or exclusions, but the topic list provides sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete, runnable recipe for a common Cited integration pattern.
Args: pattern: "python_scan" (REST scan + verdict parsing) | "agent_watch" (MCP client connect + prompt)
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | python_scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does communicate that the result is a 'complete, runnable recipe' and clarifies what each pattern covers ('REST scan + verdict parsing,' 'MCP client connect + prompt'). However, it never explicitly states that the tool returns example code rather than performing the cited operation, and it does not disclose output format or side-effect profile.
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 short, front-loaded with the purpose, and uses a clean structured 'Args' list for the parameter semantics. Every sentence earns its place and there is no filler or repetition of schema fields.
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 simple one-optional-parameter tool with no output schema, the description is mostly complete: it names the patterns and the recipe nature. The main gap is the lack of an explicit statement that this tool only returns example code and does not execute the scan or connect to a client, which would fully prevent confusion with sibling operational tools.
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?
The schema only defines a string parameter with a default and no enum, so description coverage is 0%. The description fully compensates by naming the exact allowed values ('python_scan' and 'agent_watch') and explaining what each pattern includes. This gives an agent the semantic context needed to set the parameter correctly.
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 the tool provides a 'Complete, runnable recipe for a common Cited integration pattern,' which identifies both the action (provide a recipe) and the resource (Cited integration patterns). It lists the two supported pattern variants, helping distinguish it from operational siblings like cited_scan and cited_report, though it does not explicitly contrast with documentation-style siblings like cited_api_docs.
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 is no explicit guidance on when to choose cited_examples over its siblings, nor any exclusions or prerequisites. The description only enumerates the two pattern options and their contents; an agent must infer that this is a reference/examples tool rather than a live operation. This is effectively no guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liveness check for the Cited API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Liveness check' and does not reveal expected response format, status codes, authentication requirements, or whether the call is read-only or has any side effects.
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 one concise sentence with no filler. It front-loads the tool's purpose and is immediately scannable.
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?
This is a low-complexity health check with zero parameters, so the description is largely sufficient. Still, because there is no output schema and no behavioral details, an agent might not know exactly what the response contains, but the purpose is clear enough for a liveness probe.
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?
The tool has zero parameters and no required parameters, so there is no parameter semantic gap for the description to fill. The schema fully covers the input surface, so the baseline of 4 applies.
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: 'Liveness check for the Cited API.' This clearly identifies what the tool does and distinguishes it from the sibling tools, none of which perform a generic API health check.
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?
The intended use is implied: call this tool to verify whether the Cited API is alive and responding. However, the description does not explicitly state when to prefer this over alternatives or mention any conditions like when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-fetch a previous scan result by its shareable scan_id.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Re-fetch', implying a read operation, but does not mention side effects, error behavior, required permissions, rate limits, or behavior for invalid/missing scan IDs.
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?
One concise sentence, front-loaded with the action and object. No filler or redundancy; every word contributes.
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 one-parameter read-style tool, the description communicates the core action and the required input. However, with no annotations and no output schema, an agent lacks clues about response shape, error handling, or how to discover scan_id. It is minimally sufficient but not fully complete.
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 0%, so the description must compensate. It adds meaning by clarifying that scan_id is 'shareable', hinting at its origin. However, it stops short of specifying format, where to obtain it, or validation behavior, so compensation is partial.
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?
Description uses a specific verb ('Re-fetch') and a specific resource ('previous scan result') tied to a concrete identifier (scan_id). It clearly differentiates from sibling cited_scan by targeting existing results rather than initiating scans.
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?
The description implies a use case (you need a scan_id from a prior scan) but gives no explicit guidance on when to prefer this over cited_scan or other siblings, when not to use it, or alternative tools. No conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a free instant AI-visibility scan for a local business.
Args: business: the business's name, e.g. "Sunshine Smiles Dentistry" city: city + state, e.g. "Austin, TX" category: the service category, default "dentist"
Returns per-engine verdicts, verbatim AI evidence quotes, citations, and a
cta_teaser on any check where the business wasn't the top recommendation
— the specific fix is a paid-tier ($39/mo) feature. Rate limit: 3/IP/24h.
Scan takes under 30s (single-prompt free-tier path).
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| business | Yes | ||
| category | No | dentist |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full transparency burden and does so well. It discloses the rate limit (3/IP/24h), scan duration (under 30s), free vs. paid-tier behavior, and the specific condition under which a cta_teaser is returned, giving the agent a realistic picture of side effects and constraints.
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 well-structured with an Args section, return-behavior summary, rate limit, and timing. It is appropriately concise and front-loaded, though 'free' and 'free-tier' plus 'instant' and 'under 30s' create slight redundancy without causing confusion.
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 tool with no output schema, the description compensates by explaining what is returned, when a cta_teaser appears, and the paid-tier implication. It does not enumerate the specific engines, but the information provided is sufficient for an agent to decide to invoke the tool and interpret the high-level result.
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?
The input schema provides only names, titles, and a default, with 0% schema description coverage. The description fully compensates by explaining each parameter with concrete examples and the default behavior for category, making the invocation requirements clear.
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 opens with a specific verb and resource: 'Run a free instant AI-visibility scan for a local business.' It also describes the returned artifacts (per-engine verdicts, evidence quotes, citations), making its function unmistakable and distinct from sibling tools like cited_examples or cited_stats.
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?
The description implies the tool should be used when a user wants a free AI-visibility scan for a local business, and it provides useful operational context such as rate limits and duration. However, it does not explicitly state when to prefer this over sibling tools like cited_report or cited_stats, nor does it name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Funnel counters: page views, scans run, paid registrations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It only lists metric names and does not disclose whether the tool is read-only, what the response format is, whether the data is time-bounded, or any other operational behaviors.
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 extremely concise and front-loaded, with no filler or redundant phrasing. Every word contributes to identifying the tool's core purpose.
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?
There is no output schema or annotations, so the description should clarify what 'counters' means, such as totals, ranges, or units. The listed metrics give a minimal viable understanding, but the description is sparse for a tool with no other structured context.
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?
The input schema has zero parameters, so there is no parameter documentation burden for the description to carry. The description correctly focuses on what the returned data contains.
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 identifies the tool as exposing funnel counters and enumerates the specific metrics: page views, scans run, and paid registrations. This is clear about what data is provided, though it lacks a verb and does not explicitly distinguish itself from sibling tools like cited_report.
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 is no guidance on when to use cited_stats versus siblings such as cited_report or cited_scan. The description implies it is for funnel metrics, but it does not provide context, exclusions, or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a business is on the paid weekly monitoring plan.
| Name | Required | Description | Default |
|---|---|---|---|
| business | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'Check' implies a read-only operation, but the description does not mention any side effects, required permissions, rate limits, or what happens if the business is not found. It provides no behavioral context beyond the basic action.
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 a single, concise sentence that front-loads the core purpose. There is no wasted wording, and it is efficiently structured.
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 tool with no annotations and no output schema, the description is minimally adequate. It does not explain the return value, the meaning of 'paid weekly monitoring plan', or how the business identifier should be provided. Given the low complexity, more detail would be expected to make the tool safely callable.
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 0%, so the description must explain the 'business' parameter, but it does not. It does not specify whether 'business' is an ID, name, or something else, nor its format or required values. The agent is left without any guidance on how to fill the parameter.
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 'Check' and a clear resource: whether a business is on the paid weekly monitoring plan. It clearly communicates the tool's function. However, it does not differentiate from sibling tools like cited_scan or cited_stats, so it lacks explicit sibling distinction.
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 is no guidance on when to use this tool versus alternatives. The description only states what it does, without any context about prerequisites, scenarios, or when not to use it. An agent would have to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a product skill file by its skill:// URI.
Args:
uri: e.g. skill:////SKILL.md
Get valid URIs from skills_list_tool.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the action is a read, implying non-destructive behavior, but it does not disclose return format, error handling, or any side effects. The URI format hint is useful but overlaps with parameter semantics rather than behavioral transparency.
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 two sentences with zero fluff. The main purpose is front-loaded, and the arg example is compact and directly relevant. 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?
For a simple read operation with one required parameter and no output schema, the description provides the URI format and a source for valid values. It does not explicitly state the return type, but the tool name 'read_skill' and the action 'read' make it adequately predictable. Minor omission of return details is acceptable given the low complexity.
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?
The input schema provides no description for the 'uri' parameter (0% coverage). The description compensates by giving a concrete example format (skill://<product>/<skill-name>/SKILL.md) and directing the agent to skills_list_tool for valid URIs, which adds significant meaning beyond the bare schema.
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 action ('Read a product skill file') with a specific resource (a skill:// URI) and mechanism. It also references skills_list_tool for obtaining valid URIs, differentiating it from the listing sibling.
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?
The description explicitly tells the agent where to get valid URIs (from skills_list_tool), implying a two-step pattern. It does not explicitly state when not to use this tool or list alternatives beyond that, but the context is clear enough for an agent to know it should be used after listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this product's skills. Each entry carries the SKILL.md URI,
its name and description, verbatim frontmatter, and a per-file
sha256 manifest. Read a body with read_skill.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It details exactly what each entry contains (SKILL.md URI, name, description, frontmatter, sha256 manifest), which is behavioral transparency about the return payload. It does not explicitly state read-only behavior, but the act of listing and the mention of a separate read tool strongly imply it. This is adequate for a list operation.
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 two concise sentences with no filler. The primary purpose is stated first, followed by a precise enumeration of the return contents and a clear pointer to the sibling tool. Every word 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?
For a parameterless list tool with no output schema, the description fully specifies what an agent needs: the action, the content of each entry, and how to proceed to read a skill body. No critical information is missing for correct invocation and interpretation.
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?
The tool has zero parameters, so the input schema is trivially complete (100% coverage). The description adds value by describing what the returned list entries contain, which goes beyond the schema. Since there are no parameters to explain, the baseline of 4 applies, and the description enriches the usage context.
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 begins with a specific verb and resource: 'List this product's skills.' It clearly distinguishes itself from the sibling tools by naming `read_skill` as the companion for reading a body, and the pw_* tools are clearly unrelated to listing skills. The mention of what each entry contains further clarifies the tool's exact function.
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?
The description provides clear context by stating it lists skills and explicitly directs the agent to `read_skill` for reading a body, which implies when to use this tool vs. its sibling. It does not list exclusions or alternative tools for other purposes, but for a listing operation, the guidance is sufficient.
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.
cited_api_docscited_examplescited_healthcited_reportcited_scancited_statscited_watch_statusread_skillskills_list_toolAI visibility + fact-checks (ChatGPT/Perplexity), review gaps & competitor scans, local SEO.
Live AI-visibility measurements across 7 answer engines, queryable by the business owner's own AI.
Measure how AI engines cite your brand. Cross-engine GEO visibility, as agent tools.
Local business intel for AI agents: audits, lead scoring, tech stack, prospecting.
Add one secure layer between your agents and this server.
