Would machine-readable anonymous vs authenticated access in server.json be useful?

[YE-YI7]

Exa's README explains a useful pre-call distinction: the hosted MCP works anonymously with rate limits, OAuth or an API key raises limits, and Exa Agent requires authentication. The checked-in server.json identifies the remote endpoint, but clients cannot read those access boundaries from the metadata itself.

I maintain Agent Service Manifest (ASM), an optional namespaced block for selection facts under MCP Registry publisher-provided _meta. This would not alter Exa's tools, OAuth flow, or runtime behavior. I would model only the documented anonymous/authenticated tool boundary plus provenance, and keep mutable quotas or prices behind source links.

Would the maintainers be open to reviewing a minimal server.json metadata PR plus a validation fixture? If this belongs elsewhere, I am happy to use the metadata surface you prefer.

Reference shape: https://github.com/YE-YI7/asm-spec/blob/main/docs/adoption/producer-guide.md

[dinpd]

Another downstream consumer use case for this distinction: I maintain AgentAction, and our public Exa profile currently labels credential inputs “Not specified” because the official ai.exa/exa record (version 3.4.1, checked 2026-09-24) has a remote URL but no credential-input declarations. We do not interpret that absence as proof of anonymous tool access.

The README's distinction between rate-limited anonymous use and authenticated agent_run is useful information to preserve. From a consumer perspective, any proposed metadata should let us distinguish:

• authentication required for the whole endpoint versus for a particular tool;
• optional credentials that change limits;
• declared access conditions versus what a particular account has actually been granted.

A fixture covering “anonymous base tools, authenticated agent_run” would be valuable, with quotas/prices remaining linked to their authoritative documentation as proposed above. Would the maintainers consider that a faithful representation of the intended hosted behavior? Our profile is a review surface, not a claim that account access or execution has been verified.

[YE-YI7]

@dinpd Thanks — having a concrete use case for this helps. Your point about “Not specified” not meaning “anonymous” is important; I’d keep unknown explicit in the fixture too.

For the first example, I’d separate endpoint access from tool-specific requirements, including optional credentials that raise limits or unlock tools. Actual account grants would stay out of the declared metadata, and quotas/prices would stay as documentation links.

Would a small JSON fixture be useful for testing how AgentAction displays those distinctions? I’m not proposing an integration here; I’m mainly interested in whether the shape is usable on your side. The Exa-specific values would still need maintainer confirmation.