Machine-Readable Capability Metadata
stableCategory: ai-signals · Methodology v4.5
It checks whether your site spells out its capabilities in a form machines can read.
Signal Source
- Source
homepage HTML JSON-LD blocks (potentialAction / action / *Action types), manifest, well-known- Kind
- http_response
Score Bands
| Verdict | Condition |
|---|---|
| Pass | 2 or more distinct capabilities are declared — JSON-LD potentialAction/action objects whose @type ends in 'Action' (e.g. SearchAction, ReserveAction) or that carry a name/target, de-duplicated by type and name |
| Partial | Exactly 1 capability is declared, or the definitions are vague |
| Fail | No capability metadata is detected in any parsed JSON-LD block |
Description
Machine-readable capability metadata measures whether your site declares what it can do — search, reserve, order — as JSON-LD potentialAction or action objects that AI agents can read directly. friendly4AI scans the homepage and counts distinct declared capabilities. Two or more pass (100), exactly one is partial (50), none fails (0).
What does this parameter measure?
It checks whether your site spells out its capabilities in a form machines can read. friendly4AI parses every <script type="application/ld+json"> block on the homepage and walks the tree for potentialAction and action nodes. A node counts as a capability when its @type ends in Action — for example SearchAction, ReserveAction, or OrderAction — or when it carries a name or a target URL template. Each capability gets a label from its type and name, and duplicates are dropped before the count.
Why does it matter for AI-readiness?
An agent can infer plenty from a page on its own. But a declared SearchAction or ReserveAction takes the guesswork out: it names the capability, the entry point, and often the parameters too, using the standard Schema.org vocabulary the agent already speaks. That's the difference between "this site probably lets me book something" and "this site exposes a booking action at this URL with these inputs." Declare more capabilities clearly, and an agent can carry a task through to the end with more confidence.
How is it scored?
This is a gradient AI-Specific Signals parameter. The score comes from counting distinct capabilities:
- Pass (100): 2 or more distinct capabilities declared.
- Partial (50): exactly 1 capability declared, or definitions are vague.
- Fail (0): no capability metadata detected in any parsed JSON-LD block.
Detection works entirely over parsed JSON-LD, so only valid, machine-readable structured data counts. Prose that describes your features earns nothing here. Like agent onboarding docs, this parameter sits in the AI-Specific Integration group and is not gated on API detection. Every site gets scored, because capability metadata helps agents whether or not you publish a formal API spec.
How do you fix common issues?
- Add JSON-LD
potentialActionentries to your structured data. Start with aSearchActionand the actions most central to your site. - Give each action a clear
@typeending inAction, plus anameand atargeturlTemplateso the entry point is explicit. - Declare at least two distinct capabilities to reach the pass tier. One capability only earns a partial.
- Validate your structured data at search.google.com/test/rich-results so the JSON-LD parses cleanly.
- Re-scan after publishing to confirm the capabilities are detected and de-duplicated as expected.
Related parameters
- Action API — exposing actions through a callable API.
- AI Manifests Coverage — declaring capabilities via manifests and well-known files.
- API Discoverability — making your API endpoints findable by agents.
Version History
- Introduced
- v1
- Last changed
- v4.5
Key takeaways
- Signal: homepage HTML JSON-LD blocks (potentialAction / action / *Action types), manifest, well-known
- Category: AI-Specific Signals
- Passes when: 2 or more distinct capabilities are declared — JSON-LD potentialAction/action…