Assess AI-discovery readiness, plan visibility fixes, and summarize scan evidence. Read-only.
Scored across 3 tools
Each tool has a clearly distinct purpose: analyzing readiness signals, building action plans, and summarizing evidence rates. The descriptions explicitly delineate boundaries (e.g., analyze vs. summarize) with no overlap.
All tool names follow a consistent verb_noun_qualifier pattern in snake_case (analyze_discovery_readiness, build_visibility_action_plan, summarize_scan_evidence). This creates a predictable and scannable structure.
Three tools is well-scoped for a focused evidence-analysis server. Each tool covers a distinct step in the workflow—analysis, planning, and summarization—so none feel redundant or missing.
The tool set forms a coherent non-persistent evidence workflow: assess readiness, prioritize actions, and summarize rates. While it intentionally omits fetching or persistence, those are excluded by design, leaving no obvious gaps within the stated purpose.
Score caller-supplied website and business discovery signals. This tool does not fetch the website, run an AI scan, persist data, or verify inclusion in any AI product.
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes | Caller-supplied signal observations. Omitted signals are treated as unknown. | |
| websiteUrl | No | Optional page URL used only as a label. The tool will not fetch this URL. | |
| businessName | Yes | The business name used only to label this assessment. |
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| assessment | Yes | |
| priorities | Yes | |
| websiteUrl | Yes | |
| limitations | Yes | |
| businessName | Yes | |
| readinessScore | Yes | |
| evaluatedSignals | Yes | |
| verificationNeeded | Yes | |
| evidenceCoveragePercent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive; the description adds value by explicitly listing what the tool does not do: fetch, scan, persist, or verify AI inclusion. This goes beyond the annotations and helps prevent incorrect assumptions about 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?
Two tightly written sentences with no filler. The main action is front-loaded, and the crucial limitations are listed compactly in the second sentence.
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 pure scoring tool with a rich schema, output schema, and annotations, the description covers all necessary selection and invocation context. The negative scope prevents misuse, and the schema handles parameter details.
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 schema already documents all three parameters clearly. The description adds only the general notion of 'caller-supplied signals', which maps to the schema but does not enrich parameter meaning beyond it. Baseline 3 is appropriate.
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 ('Score') and resource ('caller-supplied website and business discovery signals'), and clearly distinguishes this from likely siblings by stating it does not fetch the website, run an AI scan, or verify AI inclusion. The negative scope makes the tool's unique role immediately clear.
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 phrase 'caller-supplied signals' gives clear context for when this tool is appropriate, and the negative list implies when to look elsewhere (e.g., when website fetching or AI scanning is needed). It does not explicitly name sibling tools or give direct 'use this instead' guidance, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prioritize fixes from caller-supplied findings using a deterministic rubric. This tool does not edit a website, contact third parties, persist data, or promise rankings or mentions.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | The outcome used to break ties in the deterministic priority rubric. | |
| findings | Yes | Caller-supplied findings. Present findings are acknowledged but do not create actions. | |
| businessName | Yes | ||
| effortBudget | Yes | Controls how many actions are returned and how they are phased. |
| Name | Required | Description |
|---|---|---|
| goal | Yes | |
| scope | Yes | |
| actions | Yes | |
| goalLabel | Yes | |
| limitations | Yes | |
| businessName | Yes | |
| effortBudget | Yes | |
| omittedActionCount | Yes | |
| excludedPresentSignals | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior; the description adds substantial context by stating it does not edit websites, contact third parties, persist data, or promise rankings or mentions. Disclosing the deterministic rubric also helps the agent understand repeatability.
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?
Two sentences, front-loaded with the primary action and resource, followed by concise non-behavior exclusions. Every sentence earns its place with no filler.
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 read-only planning tool with a rich input schema and an output schema, the description sufficiently covers purpose, source of input, and behavioral boundaries. The deterministic-rubric note explains how prioritization works without requiring schema restatement.
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 coverage is high at 75%, with enums and descriptions for most parameters. The description adds little beyond what the schema already provides, though 'caller-supplied findings' reinforces that findings come from the caller rather than being discovered by the tool.
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 uses a specific verb ('Prioritize') and resource ('fixes from caller-supplied findings'), clearly distinguishing this from the sibling analysis/summarization tools. It also names what it does not do, which sharpens the boundary.
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 this tool should be used when the caller already has findings and wants prioritized fixes, but it never explicitly contrasts this with analyze_discovery_readiness or summarize_scan_evidence. The exclusions are behavioral boundaries, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate mention and business-citation rates from caller-supplied captures. This tool does not call AI providers, fetch URLs, persist data, or establish current inclusion beyond the supplied observations.
| Name | Required | Description | Default |
|---|---|---|---|
| businessName | Yes | ||
| observations | Yes | Point-in-time captures supplied by the caller. The tool will not obtain new captures. |
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| bySource | Yes | |
| limitations | Yes | |
| unavailable | Yes | |
| businessName | Yes | |
| mentionCount | Yes | |
| completedCount | Yes | |
| observedAtRange | Yes | |
| observationCount | Yes | |
| unavailableCount | Yes | |
| evidenceStatements | Yes | |
| mentionRatePercent | Yes | |
| sentimentBreakdown | Yes | |
| businessCitationCount | Yes | |
| establishesLiveInclusion | Yes | |
| businessCitationRatePercent | Yes | |
| uniqueBusinessCitationHosts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by explicitly stating the tool does not call AI providers, fetch URLs, persist data, or establish current inclusion — this clarifies the tool's limited scope beyond what annotations provide. It doesn't describe the output format, but the output schema exists and the description's exclusions are the key behavioral disclosure.
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?
Two sentences with zero waste. The first sentence states the core function, and the second sentence front-loads the critical exclusions. Every word earns its place, and the structure is ideal for an agent scanning quickly.
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 read-only calculation tool with an output schema and clear annotations, the description is nearly complete. It explains the input contract (caller-supplied captures), the computation (mention and business-citation rates), and the boundaries (no provider calls, no fetching, no persistence, no current inclusion). The only minor gap is not describing the output shape, but the output schema exists and the tool's complexity is moderate.
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 50% — the 'observations' parameter has a description ('Point-in-time captures supplied by the caller. The tool will not obtain new captures.'), but 'businessName' has no description. The tool description adds context about what the tool does with these parameters (calculates rates from captures), but doesn't add per-parameter semantics beyond the schema. With 50% coverage, the description partially compensates but doesn't fully close the gap for businessName.
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 uses a specific verb ('Calculate') and names the exact resource ('mention and business-citation rates from caller-supplied captures'). It also distinguishes itself from siblings by explicitly stating what it does NOT do (call AI providers, fetch URLs, persist data, establish current inclusion). This makes the tool's purpose unmistakable.
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 clearly states the tool operates on caller-supplied captures and explicitly lists exclusions (does not call AI providers, fetch URLs, persist data, or establish current inclusion). This gives strong context for when to use it, though it doesn't explicitly name alternative tools or provide a when-not-to-use condition beyond the exclusions.
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.
analyze_discovery_readinessbuild_visibility_action_plansummarize_scan_evidenceRead-only AI search visibility data: citations, AEO audits, and advisor insights from AI-Advisors.
Scan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Read-only local AI advice, shared reports and website audits. No PC scan or local actions.
Add one secure layer between your agents and this server.
