Wellknown

Resolve one capability by identifier

get_capability

Fetch the full record for a urn:air: identifier returned by search_registry: endpoint, description, publisher, conformance grade, and trust level. Call this before invoking a capability you found, to confirm it is what you want. Your own granted identifiers (urn:air::granted::) resolve here too, including the tool's input schema. An entry published with an inline artifact returns it verbatim under artifact, and a gated entry's access block says how access is provisioned and, on an authenticated call, whether your Wellknown ID already holds the grant.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`from_query`	No	Optional. The queryId from the search_registry response that led you here. Passing it lets the registry learn which results were actually useful, which improves ranking for everyone. Nothing about you is stored beyond your client name.
`identifier`	Yes	A urn:air: identifier.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so admirably. It discloses the record contents (endpoint, description, publisher, conformance grade, trust level), the behavior for inline artifacts (returned verbatim under `artifact`), gated entries (access block explains provisioning), and authentication effects (whether Wellknown ID holds the grant). This is rich, non-obvious behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each densely informative without redundancy. It front-loads the core action, then provides usage guidance, then details edge cases (inline artifact, gated entry, authentication). Every clause adds value; there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a lookup tool with no output schema and no annotations, the description covers the main response fields, special cases (inline vs gated), authentication behavior, and even the telemetry side-effect of `from_query`. It gives the agent everything needed to invoke and interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers both parameters with 100% coverage, so baseline is 3. The description adds value by explaining the identifier format ('urn:air: identifier') and the purpose of `from_query` (letting the registry learn useful results, with a privacy note). This goes beyond the schema's basic descriptions, warranting a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear, specific verb+resource: 'Fetch the full record for a urn:air: identifier returned by search_registry'. It also distinguishes from siblings by focusing on resolving a single known identifier rather than searching or catalog generation, making it unique among the sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Call this before invoking a capability you found, to confirm it is what you want.' This provides a clear directive that separates it from search_registry (which finds candidates) and other siblings. It also notes that granted identifiers resolve here, adding an additional use case without ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Wellknown tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a clearly distinct responsibility: audit_domain checks a live domain's discoverability and trust across ARD paths, while validate_catalog checks a static document against schema rules. search_registry and get_capability follow the classic query-versus-fetch-by-ID pattern. No two tools would plausibly compete for the same call.

Naming Consistency5/5

Every tool follows a strict lowercase snake_case verb_noun pattern: audit_domain, generate_catalog, get_capability, search_registry, validate_catalog. The two catalog-related tools use distinct leading verbs (generate vs. validate) that reinforce their different purposes rather than confusing them.

Tool Count5/5

At 5 tools, the server is lean and well-scoped, sitting squarely in the ideal 3-15 range. Each tool maps to a distinct stage of the ARD lifecycle—search, fetch, generate, validate, audit—with no redundancy or bloat.

Completeness5/5

The toolset covers the full agent workflow end-to-end: search and get for discovery, generate and validate for authoring, and audit for trust assessment. There are no dead ends or fabricated outputs, as generate_catalog explicitly returns underivable fields as a to-do list, and the domain doesn't obviously require update/delete or registration tools.

Resources

Need Help?