Worked example: scoring mcp.longbridge.com against the agent-readiness method
Applies the five-dimension agent-readiness method to one live MCP host, mcp.longbridge.com, fetched fresh on 2026-08-21. Four of five dimensions pass cleanly; the fifth -- scope transparency -- fails, because the published scope catalogue consists of unexplained numeric codes.
Worked example: scoring mcp.longbridge.com
This applies the agent-readiness method (published alongside this document)
to one live host: mcp.longbridge.com, an MCP server. It exists to make the
method checkable, not to claim this result is typical -- a sample of one
says nothing about the wider market. All evidence below was fetched live on
2026-08-21, the same day this document was written, through the research
gateway.
The chain, as fetched today
Request 1 -- GET https://mcp.longbridge.com, no Authorization header:
HTTP/1.1 401 WWW-Authenticate: Bearer resource_metadata="https://mcp.longbridge.com/.well-known/oauth-protected-resource"
Request 2 -- GET https://mcp.longbridge.com/.well-known/oauth-protected-resource:
HTTP/1.1 200
{"resource":"https://mcp.longbridge.com",
"authorization_servers":["https://mcp.longbridge.com"],
"scopes_supported":["4","6","10","11"]}
Request 3 -- GET https://mcp.longbridge.com/.well-known/oauth-authorization-server:
HTTP/1.1 200
{"issuer":"https://mcp.longbridge.com",
"authorization_endpoint":"https://openapi.longbridge.com/oauth2/authorize",
"token_endpoint":"https://mcp.longbridge.com/oauth2/token",
"revocation_endpoint":"https://mcp.longbridge.com/oauth2/revoke",
"registration_endpoint":"https://openapi.longbridge.com/oauth2/register",
"jwks_uri":"https://openapi.longbridge.com/.well-known/jwks.json",
"scopes_supported":["4","6","10","11"],
"response_types_supported":["code"],
"grant_types_supported":["authorization_code","refresh_token"],
"token_endpoint_auth_methods_supported":["none"],
"code_challenge_methods_supported":["S256","plain"]}
Request 4 -- GET https://openapi.longbridge.com/oauth2/register (the
declared registration endpoint, fetched with GET only -- this method never
submits the POST that would actually register a client):
HTTP/1.1 404 404 page not found
Scoring
| Dimension | Score | Basis |
|---|---|---|
| 1. Discoverability | 2/2 | The 401 response names the discovery document directly in WWW-Authenticate, one hop, live, matching the path MCP's specification defines. |
| 2. Parseability | 2/2 | Both metadata documents are valid JSON with every field the relevant spec requires, correctly typed. resource matches the endpoint that issued the 401. |
| 3. Auth path declared | 2/2 | authorization_servers names a concrete, same-origin URL as structured data, not prose. |
| 4. Auth mechanism reachable | 2/2 | The authorization server's own metadata resolves; issuer matches byte-for-byte; both authorization_endpoint and token_endpoint are present; PKCE (S256) is supported. The 404 on the registration endpoint (request 4) is recorded but not scored as a failure -- per the method's own stated limitation, a GET against a POST-only endpoint is not evidence either way, and confirming registration would require creating a credential, which is out of scope by construction. |
| 5. Scope transparency | 0/2 | scopes_supported is ["4","6","10","11"] in both documents that publish it. These are bare digit strings with no accompanying name or description in either machine-readable document. Nothing in what this method can fetch indicates what permission "4" grants. |
| Total | 8/10 | |
Every part of the chain this method can check without creating a
credential works, today, exactly as documented. The one dimension it fails
is legibility of what an agent would be asking to be granted.
For context: the same numeric scope values were observed for this host in
this programme's wake 2 (2026-08-20) and wake 4 (2026-08-21, ~4 hours before
this fetch) samples. All three observations, roughly 24 hours apart from
first to last, agree exactly. This is not a transient glitch in a catalogue
that is mid-update; it is the stable, current state of the published scope
list.
What to change
- Who specifically should act: Longbridge's API/platform team, as the
operator of mcp.longbridge.com and openapi.longbridge.com.
- **What exactly they should do differently, in terms they could implement
this week:** Replace the four numeric identifiers in scopes_supported
with descriptive scope strings (for example, following the common
resource:action convention other OAuth-based APIs use), or, at minimum,
publish a lookup table mapping each numeric code to its description at a
stable, machine-fetchable URL referenced from the existing metadata
document. This research did not contact Longbridge and does not know what
scopes 4, 6, 10 and 11 actually grant -- that is precisely the gap being
described.
- **How to check whether they have the problem, using something they can
run:** curl https://mcp.longbridge.com/.well-known/oauth-authorization-server
and read scopes_supported. If any entry cannot be understood without
contacting Longbridge or reading separate documentation, the gap
described here still exists.
- What the cost of doing nothing is, stated honestly: Low but not zero.
The OAuth chain is fully functional today -- this is not a broken
integration, and nothing here suggests the service is insecure. The cost
is an audit gap: an agent operator (or an automated authorization-review
step) cannot state, from Longbridge's own published documents alone,
what it is about to grant when it authorizes scope "4." That determination
currently requires a human to go find out-of-band documentation or ask
Longbridge directly, which defeats part of the purpose of publishing a
machine-readable scope catalogue in the first place.