Free AI visibility and GEO audit: see what AI reads on your site and whether its answers cite you.
Scored across 5 tools
Each tool serves a distinct audit phase: planning, crawler access, page inspection, answer-level citation analysis, and platform-level source landscape. The only potential overlaps—page inspection vs. crawler access and platform source mix vs. a specific answer's sources—are clearly separated by descriptions and scope.
All tools use the same surfacedby_ prefix and a consistent verb_noun-style snake_case pattern: analyze_answer_evidence, check_ai_crawler_access, get_ai_source_landscape, inspect_page_evidence, plan_ai_visibility_audit. The naming is predictable and easy to scan.
Five tools is well-scoped for an audit workflow, with each tool corresponding to a recognizable step rather than redundant variations. No tool appears superfluous, and the set is not so thin that steps are missing by count alone.
The surface covers planning, access checks, page evidence, pasted-answer analysis, and published landscape data, but it cannot actually run AI queries or directly measure whether a business appears in model answers. That is a notable gap for an AI visibility audit, leaving agents dependent on external answer collection to complete the core workflow.
Check one AI answer the user pasted: whether it cites the business with a link, names it without one, or leaves it out. Classifies cited sources, such as review sites, best-of lists, forums, competitors and the business's own pages, reads Google and Gemini redirect links to their destinations, and summarizes the visible source mix. Suggests verification against the linked sources or the business's own pages. The answer alone cannot establish why a model omitted the business. Runs no AI queries and does not verify factual claims without separate page inspection.
| Name | Required | Description | Default |
|---|---|---|---|
| answer | Yes | ||
| language | No | ||
| platform | No | ||
| brand_name | No | ||
| business_url | Yes | ||
| competitor_domains | No |
| Name | Required | Description |
|---|---|---|
| platform | No | |
| presence | Yes | |
| next_steps | No | |
| limitations | No | |
| answer_sha256 | Yes | |
| cited_sources | No | |
| evidence_kind | No | |
| matched_terms | Yes | |
| visible_citations | Yes | |
| business_citations | Yes | |
| brand_name_ambiguous | Yes | |
| source_concentration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/openWorld/idempotent annotations covering the safety profile, the description still adds real value: it resolves Google and Gemini redirect links, classifies source types, and explicitly limits itself ('cannot establish why a model omitted the business', no AI queries, no factual verification). It does not discuss response latency or fetch failures, but the substantive behavioral limits are disclosed.
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 core check is front-loaded in the first sentence, and each subsequent sentence adds distinct information — classification scope, redirect handling, suggested follow-up, and limits. It is somewhat dense at five sentences, but nothing is purely redundant.
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?
An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. Given six parameters with no schema descriptions, the description covers purpose, behavior, and boundaries well, though it leaves gaps on parameter-level meaning (platform/language) that would help an agent call it correctly.
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 0% across six parameters, so the description must carry the full burden. It gives context for the answer and competitor input ('competitors', 'the business'), but never explains the role of `language`, `platform`, or how `brand_name` differs from `business_url`, leaving meaningful ambiguity for half the parameters.
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 gives a specific verb and object — 'Check one AI answer the user pasted' — and enumerates the three outcomes (cites with link, names without link, leaves out). It does not explicitly contrast itself with siblings like get_ai_source_landscape or inspect_page_evidence, so an agent must infer the distinction, but the scope is unambiguous.
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 pasted-answer framing makes clear when to invoke it, and the closing sentences ('Runs no AI queries and does not verify factual claims without separate page inspection') provide when-not guidance that implicitly routes verification work to the page-inspection sibling. It stops short of naming an explicit alternative tool or prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check which AI crawlers a site allows, restricts or blocks in robots.txt, what that means for each AI platform and the search index it reads, where to submit pages, whether a security challenge answers an ordinary request, homepage noindex, llms.txt and Content-Signal, with copy-ready fixes. Reads the site's public files and one ordinary page request; firewall rules keyed to crawlers' own IP addresses are not visible.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| fixes | Yes | |
| budget | No | |
| domain | Yes | |
| crawlers | Yes | |
| homepage | Yes | |
| llms_txt | Yes | |
| platforms | Yes | |
| next_steps | No | |
| robots_txt | Yes | |
| limitations | No | |
| observed_at | Yes | |
| evidence_kind | No | |
| content_signal | Yes | |
| evidence_provider | No | |
| citation_crawlers_blocked | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds genuine behavioral value by disclosing exactly what it touches (public files plus one ordinary page request) and an important limitation (firewall rules keyed to crawler IPs are not visible), which the agent could not infer otherwise.
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?
A single front-loaded sentence leads with the core purpose and then enumerates coverage areas, each clause adding distinct scope information rather than filler. It is dense and slightly run-on, but no sentence is wasted.
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?
With an output schema present, return values need not be described, and the description already covers scope, network behavior, and a meaningful blind spot. An agent has enough to decide whether to call it and what it will and won't see.
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% for the single 'domain' parameter, so the description carries the burden but adds no semantics — no statement of whether it takes a bare domain, a hostname, or a full URL (the 2048-char max hints URLs may be accepted). The parameter is nearly self-evident, so this is a minor but real gap.
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+resource (check AI crawler access implicated by robots.txt) and enumerates concrete coverage areas: per-platform meaning, search index, submission points, security challenges, homepage noindex, llms.txt and Content-Signal. It is clearly distinguishable from siblings like inspect_page_evidence or get_ai_source_landscape in substance, but never explicitly names a sibling to route against.
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 when-to-use / when-not-to-use statement and no named alternative, so the agent must infer applicability from the enumerated checks. The feature list makes the implied scope reasonably clear (site-level crawler accessibility audit), which lands in 'implied usage' territory rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show, for each AI platform, the mix of source types it cites, recent shifts in specific sources and how its answers cite, from SurfacedBy's published AI Search Index, with the data date, the public page and related research findings with links. Rates are pooled across many brands and describe each platform, not any one business.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | ||
| platform | No |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| platforms | No | |
| next_steps | No | |
| source_url | Yes | |
| limitations | No | |
| window_days | No | |
| data_through | No | |
| evidence_kind | No | |
| corpus_answers | No | |
| corpus_citations | No | |
| research_findings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuine context beyond annotations: the provenance (published AI Search Index), the inclusion of data date, a public page and linked research findings, and critically the pooled-across-brands scope limitation. It does not mention rate limits or freshness cadence.
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 core action and resource, then the scope caveat. Dense but each clause carries information (source mix, shifts, citation behavior, provenance, date, links). Not padded.
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?
An output schema exists, so return values need not be explained, and the description focuses on what the tool covers plus a key scope limitation. Given a read-only index tool, this is nearly sufficient; the missing parameter guidance is the only notable gap.
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% and the description never mentions the 'topic' or 'platform' parameters. With two undocumented enum parameters, the description should compensate but does not explain how the enums narrow the result or what combinations mean. The enum values are self-evident as strings but no semantic guidance is provided.
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?
States a specific verb ('Show') and a well-defined resource: the mix of source types each AI platform cites, recent source shifts, and citation behavior, drawn from SurfacedBy's AI Search Index. This is clearly a platform-level landscape view. It does not explicitly name or differentiate from the sibling tools, keeping it from a 5.
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 when-to-use or when-not-to-use guidance, but the scope caveat ('Rates are pooled across many brands and describe each platform, not any one business') implicitly signals that per-business questions belong elsewhere, e.g. inspect_page_evidence or analyze_answer_evidence. Usage remains inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read up to five public pages the way an AI crawler receives them, without running JavaScript. Returns sourced sections, table cells, internal and outside links and declared structured data, plus each page's type, source type and readiness findings with the documentation behind them, repeated declared facts to review, and the remaining request budget. Partial or unreadable pages are reported as such. Runs no AI queries and measures no visibility.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes |
| Name | Required | Description |
|---|---|---|
| pages | Yes | |
| budget | No | |
| status | Yes | |
| next_steps | No | |
| limitations | No | |
| evidence_kind | No | |
| evidence_provider | No | |
| declaration_review | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds meaningful behavior beyond that: no JavaScript execution, a five-page cap, partial/unreadable pages are reported rather than silently dropped, and the response includes the remaining request budget (an implicit quota cue).
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?
Front-loads the core action, then sequences returns, failure handling and scope exclusions in two short follow-on sentences. The return enumeration is dense but every element earns its place; nothing is padding.
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?
An output schema exists, so return values need not be restated, yet the description still frames them usefully. Combined with the JS-off caveat, page cap, partial-page reporting and budget disclosure, an agent has everything needed to invoke this correctly.
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?
There is a single parameter with 0% schema description coverage, so the description must carry the semantics. It contributes the constraint that pages must be 'public' and repeats the five-item cap already encoded in maxItems, but adds no format or syntax guidance for the urls array.
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?
States a specific verb (read) and resource (public pages as an AI crawler receives them) with a hard scope (up to five, no JavaScript), and enumerates exactly what the result contains. This is clearly distinguishable from siblings like surfacedby_analyze_answer_evidence and surfacedby_check_ai_crawler_access.
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?
Gives clear usage context (auditing how AI crawlers see pages) and a negative exclusion ('Runs no AI queries and measures no visibility'), which tells the agent what this tool is not for. It never names the sibling that should be used instead for those tasks, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the ordered checklist for an AI visibility audit of a business website: each step, the tools for it, the quality bar for the result, the rules to follow, the published research findings that apply to the goal, and the remaining request budget. Makes no request to the website.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| market | No | ||
| language | No | ||
| competitors | No | ||
| business_url | Yes |
| Name | Required | Description |
|---|---|---|
| goal | Yes | |
| steps | Yes | |
| budget | No | |
| market | No | |
| language | No | |
| tracking | Yes | |
| goal_label | Yes | |
| guardrails | Yes | |
| quality_bar | Yes | |
| business_url | Yes | |
| evidence_kind | No | |
| workflow_rule | Yes | |
| method_version | Yes | |
| goal_description | Yes | |
| known_competitors | No | |
| research_findings | Yes | |
| interpreting_results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds genuine value: 'Makes no request to the website' rules out an implicit fetch, and 'the remaining request budget' discloses that the response is budget-aware — context the annotations do not convey.
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?
A single sentence, front-loaded with the deliverable before the contents list, and the no-request caveat is placed last where it reads as a qualifier. Dense but every clause maps to a real property of the response; slightly long for one 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?
An output schema exists, so the enumerated return contents are redundant but harmless, and the read-only profile is covered by annotations. The gap is input-side: with 0% schema coverage, an agent still cannot tell how market/language/competitors alter the plan or what the four goal values do.
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% across five parameters, so the description carries the full burden and largely fails. It gestures at 'goal' (research findings that apply to the goal) and the business website, but says nothing about how 'market', 'language', or 'competitors' shape the plan, nor what the goal enum values actually select.
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?
States a specific verb and resource — 'Return the ordered checklist for an AI visibility audit of a business website' — and enumerates what the checklist contains. It is distinguishable from siblings like check_ai_crawler_access or inspect_page_evidence because it produces a plan rather than evidence, though it never names those alternatives to sharpen the contrast.
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?
Usage is implied rather than stated: the word 'Plan' plus 'Makes no request to the website' signals this is a cheap preparatory step, but there is no explicit 'call this first' instruction or 'use X instead when Y' routing against the four sibling tools. An agent must infer its position in the workflow.
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.
surfacedby_analyze_answer_evidence3 fields changedOutput schema / $defs / AnswerDiagnosisRemoved value: -{
- "additionalProperties": false,
- "description": "Why an answer that does not cite the business most likely leaves it out.",
- "properties": {
- "basis": {
- "title": "Basis",
- "type": "string"
- },
- "failure_mode": {
- "title": "Failure Mode",
- "type": "string"
- },
- "label": {
- "title": "Label",
- "type": "string"
- },
- "play": {
- "title": "Play",
- "type": "string"
- }
- },
- "required": [
- "failure_mode",
- "label",
- "play",
- "basis"
- ],
- "title": "AnswerDiagnosis",
- "type": "object"
-}Output schema / $defs / SourceConcentration / descriptionAdded value: +"Format mix among outside links, excluding owned, competitor and untyped links.\n\nCounts and shares describe this format-bearing subset, not all visible citations."Output schema / properties / diagnosisRemoved value: -{
- "anyOf": [
- {
- "$ref": "#/$defs/AnswerDiagnosis"
- },
- {
- "type": "null"
- }
- ],
- "default": null
-}surfacedby_plan_ai_visibility_audit2 fields changedOutput schema / $defs / NextStepRemoved value: -{
- "additionalProperties": false,
- "description": "A deterministic pointer to the audit step this result supports next.",
- "properties": {
- "action": {
- "title": "Action",
- "type": "string"
- },
- "step": {
- "title": "Step",
- "type": "string"
- },
- "tool": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Tool"
- }
- },
- "required": [
- "step",
- "action"
- ],
- "title": "NextStep",
- "type": "object"
-}Output schema / properties / next_stepsRemoved value: -{
- "items": {
- "$ref": "#/$defs/NextStep"
- },
- "title": "Next Steps",
- "type": "array"
-}surfacedby_analyze_answer_evidence11 fields changedInput schema / properties / competitor_domainsAdded value: +{
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 10,
+ "title": "Competitor Domains",
+ "type": "array"
+}Input schema / properties / platformAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "chatgpt",
+ "perplexity",
+ "gemini",
+ "claude",
+ "ai_mode",
+ "grok",
+ "deepseek",
+ "other"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Platform"
+}Output schema / $defs / AnswerDiagnosisAdded value: +{
+ "additionalProperties": false,
+ "description": "Why an answer that does not cite the business most likely leaves it out.",
+ "properties": {
+ "basis": {
+ "title": "Basis",
+ "type": "string"
+ },
+ "failure_mode": {
+ "title": "Failure Mode",
+ "type": "string"
+ },
+ "label": {
+ "title": "Label",
+ "type": "string"
+ },
+ "play": {
+ "title": "Play",
+ "type": "string"
+ }
+ },
+ "required": [
+ "failure_mode",
+ "label",
+ "play",
+ "basis"
+ ],
+ "title": "AnswerDiagnosis",
+ "type": "object"
+}Output schema / $defs / CitedSourceAdded value: +{
+ "additionalProperties": false,
+ "description": "One link an answer cites, classified by what kind of source it is.",
+ "properties": {
+ "destination": {
+ "title": "Destination",
+ "type": "string"
+ },
+ "domain": {
+ "title": "Domain",
+ "type": "string"
+ },
+ "owner": {
+ "enum": [
+ "business",
+ "competitor",
+ "third_party"
+ ],
+ "title": "Owner",
+ "type": "string"
+ },
+ "redirect": {
+ "anyOf": [
+ {
+ "enum": [
+ "resolved",
+ "unresolved"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Redirect"
+ },
+ "source_type": {
+ "title": "Source Type",
+ "type": "string"
+ },
+ "source_type_label": {
+ "title": "Source Type Label",
+ "type": "string"
+ },
+ "url": {
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "destination",
+ "domain",
+ "source_type",
+ "source_type_label",
+ "owner"
+ ],
+ "title": "CitedSource",
+ "type": "object"
+}Output schema / $defs / NextStepAdded value: +{
+ "additionalProperties": false,
+ "description": "A deterministic pointer to the audit step this result supports next.",
+ "properties": {
+ "action": {
+ "title": "Action",
+ "type": "string"
+ },
+ "step": {
+ "title": "Step",
+ "type": "string"
+ },
+ "tool": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Tool"
+ }
+ },
+ "required": [
+ "step",
+ "action"
+ ],
+ "title": "NextStep",
+ "type": "object"
+}Output schema / $defs / SourceConcentrationAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "classified_sources": {
+ "title": "Classified Sources",
+ "type": "integer"
+ },
+ "dominant_share_percent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Dominant Share Percent"
+ },
+ "dominant_source_type": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Dominant Source Type"
+ },
+ "placement_dominant": {
+ "default": false,
+ "title": "Placement Dominant",
+ "type": "boolean"
+ },
+ "placement_share_percent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Placement Share Percent"
+ }
+ },
+ "required": [
+ "classified_sources"
+ ],
+ "title": "SourceConcentration",
+ "type": "object"
+}Output schema / properties / cited_sourcesAdded value: +{
+ "items": {
+ "$ref": "#/$defs/CitedSource"
+ },
+ "title": "Cited Sources",
+ "type": "array"
+}Output schema / properties / diagnosisAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/AnswerDiagnosis"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / next_stepsAdded value: +{
+ "items": {
+ "$ref": "#/$defs/NextStep"
+ },
+ "title": "Next Steps",
+ "type": "array"
+}Output schema / properties / platformAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Platform"
+}Output schema / properties / source_concentrationAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/SourceConcentration"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}surfacedby_check_ai_crawler_accesssurfacedby_get_ai_source_landscapesurfacedby_inspect_page_evidence10 fields changedOutput schema / $defs / BudgetAdded value: +{
+ "additionalProperties": false,
+ "description": "Remaining shared outbound allowance, so a model can plan its next calls.\nCached evidence costs nothing; every fresh request counts, including\nrobots.txt reads and redirects.",
+ "properties": {
+ "daily_remaining": {
+ "title": "Daily Remaining",
+ "type": "integer"
+ },
+ "monthly_remaining": {
+ "title": "Monthly Remaining",
+ "type": "integer"
+ },
+ "per_site_daily_limit": {
+ "title": "Per Site Daily Limit",
+ "type": "integer"
+ },
+ "sites_remaining_today": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "title": "Sites Remaining Today",
+ "type": "object"
+ }
+ },
+ "required": [
+ "daily_remaining",
+ "monthly_remaining",
+ "per_site_daily_limit"
+ ],
+ "title": "Budget",
+ "type": "object"
+}Output schema / $defs / NextStepAdded value: +{
+ "additionalProperties": false,
+ "description": "A deterministic pointer to the audit step this result supports next.",
+ "properties": {
+ "action": {
+ "title": "Action",
+ "type": "string"
+ },
+ "step": {
+ "title": "Step",
+ "type": "string"
+ },
+ "tool": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Tool"
+ }
+ },
+ "required": [
+ "step",
+ "action"
+ ],
+ "title": "NextStep",
+ "type": "object"
+}Output schema / $defs / PageEvidence / properties / extraction_version / defaultPrevious value: -"5"New value: +"6"Output schema / $defs / PageEvidence / properties / page_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Page Type"
+}Output schema / $defs / PageEvidence / properties / readinessAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/PageReadiness"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / $defs / PageEvidence / properties / source_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Source Type"
+}Output schema / $defs / PageReadinessAdded value: +{
+ "additionalProperties": false,
+ "description": "How a non-JavaScript reader receives the page, from the readiness rules.",
+ "properties": {
+ "canonical_points_elsewhere": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Canonical Points Elsewhere"
+ },
+ "canonical_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Canonical Url"
+ },
+ "findings": {
+ "items": {
+ "$ref": "#/$defs/ReadinessFinding"
+ },
+ "title": "Findings",
+ "type": "array"
+ },
+ "indexing": {
+ "enum": [
+ "indexable",
+ "noindex",
+ "unknown"
+ ],
+ "title": "Indexing",
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Limitations",
+ "type": "array"
+ },
+ "minor_findings": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Minor Findings",
+ "type": "array"
+ },
+ "rendering": {
+ "enum": [
+ "readable",
+ "shell",
+ "unknown"
+ ],
+ "title": "Rendering",
+ "type": "string"
+ },
+ "schema_types": {
+ "items": {
+ "type": "string"
+ },
+ "title": "Schema Types",
+ "type": "array"
+ }
+ },
+ "required": [
+ "rendering",
+ "indexing"
+ ],
+ "title": "PageReadiness",
+ "type": "object"
+}Output schema / $defs / ReadinessFindingAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "title": "Action",
+ "type": "string"
+ },
+ "category": {
+ "title": "Category",
+ "type": "string"
+ },
+ "detail": {
+ "title": "Detail",
+ "type": "string"
+ },
+ "documentation": {
+ "title": "Documentation",
+ "type": "string"
+ },
+ "impact": {
+ "title": "Impact",
+ "type": "string"
+ },
+ "rule": {
+ "title": "Rule",
+ "type": "string"
+ },
+ "severity": {
+ "enum": [
+ "high",
+ "medium"
+ ],
+ "title": "Severity",
+ "type": "string"
+ },
+ "title": {
+ "title": "Title",
+ "type": "string"
+ }
+ },
+ "required": [
+ "rule",
+ "category",
+ "severity",
+ "title",
+ "impact",
+ "action",
+ "detail",
+ "documentation"
+ ],
+ "title": "ReadinessFinding",
+ "type": "object"
+}Output schema / properties / budgetAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Budget"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / next_stepsAdded value: +{
+ "items": {
+ "$ref": "#/$defs/NextStep"
+ },
+ "title": "Next Steps",
+ "type": "array"
+}surfacedby_plan_ai_visibility_auditsurfacedby_analyze_answer_evidencesurfacedby_inspect_page_evidenceFree AI visibility (GEO/AEO) audit: can ChatGPT, Claude and Perplexity find and cite your website?
Free SEO/GEO audits of public websites and AI answer-engine citation checks. No login or API key.
Free AI visibility check: is your business cited when customers ask AI? Score plus competitors.
Free SEO, GEO, and AEO audits: analyze any page or domain, AI-crawler access, agent readiness.
Add one secure layer between your agents and this server.
