# Track what shapes the agent experience.

> See which agent-facing technologies our site check detects today, like robots.txt, llms.txt, structured data and declared WebMCP forms, and what is coming later.

- Canonical URL: https://aiscovery.io/technology
- Markdown version: https://aiscovery.io/technology.md
- Last updated: 2026-10-21

Inventory established foundations and emerging agent interfaces without confusing presence with readiness.

- [Review the methodology](https://aiscovery.io/methodology)
- [Request a demo](https://aiscovery.io/demo)

## Technology presence is a signal, not the outcome.

Today Aiscovery records what our checker detects on your public pages. Validating declared tools and testing whether they help a real task are coming later.

### Lifecycle describes the technology.

Lifecycle labels indicate ecosystem maturity. They do not grade an individual website.

- `established`: Stable web foundations with broad implementation expectations.
- `widely_adopted`: Common production practice with meaningful ecosystem support.
- `emerging`: Growing adoption or active standardization with changing implementations.
- `experimental`: Early capability that needs explicit version and environment context.
- `deprecated`: Superseded behavior that may create compatibility or maintenance risk.
- `unknown`: Insufficient evidence to assign a reliable lifecycle state.

### State describes the audited site.

A detected surface is not treated as useful until validation or a task run proves it.

- `detected`: A relevant surface or declaration was found.
- `validated`: Syntax passed a focused check, for example JSON-LD syntax. Schema and behavior checks are coming later.
- `task_tested`: Coming later: the capability was used inside a real AI agent task run.
- `not_detected`: No supported evidence was found in the audited scope.
- `unsupported`: The current runner or environment cannot evaluate it reliably.

## Presence becomes evidence in four steps.

Each stronger state requires a new artifact, from a detected declaration to a verified customer outcome.

1. **Detect the surface.** Record the declaration, endpoint, DOM signal or machine-readable file with its source and timestamp.
2. **Validate the contract.** Check syntax today. Schema, permissions, freshness and parity checks are coming later.
3. **Exercise the capability.** Coming later: use it inside a bounded AI agent task and keep the step log, timing and step screenshots.
4. **Verify the outcome.** Coming later: check the final state and create a fix only when reliability, safety or task completion changed.

## The inventory spans the whole customer journey.

Signals remain grouped by the job they perform. Today the site check covers reachability, redirects, robots.txt, sitemaps, page basics, structured data syntax and AI-facing files. Items marked Coming later need AI agent task tests.

### Reach and interpret

Can an agent reach the canonical content and understand its structure?

- HTTP, redirects, TLS and canonicalization
- robots.txt, sitemap and crawl policy
- Page titles, headings and page language
- Structured data syntax

### Render and act

Does the browser surface stay operable as data and layout change?

- Coming later: JavaScript rendering and hydration
- Coming later: forms and validation
- Coming later: layout stability during agent tasks
- Coming later: network behavior during agent tasks

### Connect and govern

Are agent-native channels explicit, authorized and observable?

- Coming later: OpenAPI descriptions and structured errors
- Declared WebMCP forms: detected (declared). MCP endpoints: coming later
- llms.txt, llms-full.txt and content bundles
- Security headers such as Content Security Policy

## Emerging interfaces remain optional and versioned.

Their absence is reported as capability state, never counted as a defect.

- **WebMCP:** Detected (declared) when a page declares WebMCP forms. Inspecting tools, confirmations and browser fallback is coming later.
- **MCP and OpenAPI:** Coming later: validating schemas, permissions, authentication and safe read or write boundaries. We don't call MCP endpoints or OpenAPI operations yet.
- **llms.txt and llms-full.txt:** Check that they are available and readable. They are optional and never lower your result.

## A signal matters when it changes task reliability.

Coming later with AI agent task tests: technical observations connected to the step and the checked final state.

- **Accessibility tree:** An accessible name can determine whether the agent identifies the intended control.
- **Layout stability:** CLS and local target movement can invalidate an action after the plan was correct.
- **Content parity:** Visible, structured and bundled facts must describe the same current state.
- **Tool boundaries:** Permissions and confirmations determine whether an agent-native action is safe to run.

## Technology inventory questions

**Q: Does every site need WebMCP or MCP?**

A: No. Browser and search readiness are useful independent channels. Declared agent-native surfaces are detected when present; running them is coming later.

**Q: Does llms.txt improve rankings?**

A: Aiscovery does not assume a ranking benefit. It is treated as an auxiliary content and navigation signal.

**Q: Can a detected technology still fail a task?**

A: Yes. Detection proves presence only. Validation and task testing provide stronger evidence.

## Connect technology state to a customer journey.

Review the audit model or request a demo of AI agent task tests on your store.

- [Review the methodology](https://aiscovery.io/methodology)
- [Request a demo](https://aiscovery.io/demo)

---

This is the Markdown version of the page for AI agents. The HTML page at the canonical URL is authoritative. Site index: https://aiscovery.io/llms.txt