LLPRO Campus

Check whether an agent's card, its domain and its published key agree. Shows control of a domain, not who the operator is in law

agent_identity_check

Read-onlyIdempotent

Does this agent's card agree with the domain that served it and the keys that domain publishes? Send an agent card URL (https) or a domain. We read the card through a safe fetcher and check: required fields; that the domain the card names is the host it was served from; that the operator publishes the same agent id or key at a well-known path on that domain (/.well-known/agent-identity.json or the JWKS); and that a key proves control (the card's own JWS signature, or a signed challenge: a key a card only names, without proof, gives cannot_tell). Get back matches, does_not_match or cannot_tell, every check listed, signed by LLPRO with the time we looked. Shows control of a domain and a consistent card, NOT who the operator is in law, NOT legal identity, NOT safety. It does not show that the agent does what it says, that the domain is not hijacked or the key not stolen, or anything before the time we looked. Not a certification and not a guarantee. Free. Your card address and challenge are not stored; no model. Feeds Identity and payment rails: one input to a decision to deal with an agent, never the whole decision. Limits: public https hosts only (port 443, ASCII domain names), one JSON card up to 200,000 characters, at most 4 fetches per call (a domain tries two card paths). Fetches with the user agent 'Countersign/1.0 (independent checker; LLPRO)'; robots.txt is not read.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "agent_identity_check"
  }
}

Input Schema

Name	Required	Description
`domain`	No	A bare domain such as example.com; we try /.well-known/agent-card.json then /.well-known/agent.json.
`card_url`	No	https URL of the agent card, for example https://example.com/.well-known/agent-card.json. Give this or domain.
`challenge`	No	Optional proof you hold the key: sign the text 'llpro-agent-identity-check/v1', a newline, the domain, a newline, your nonce, a newline and the time (UTC like 2026-11-12T09:00:00Z, within 10 minutes of now) with the agent's Ed25519 key.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive; the description goes far beyond them by disclosing the safe fetcher, user agent string, that robots.txt is ignored, that the card address and challenge are not stored, and that results are LLPRO-signed with a timestamp. Some of this is genuinely valuable, but the annotation set (notably openWorldHint=false) sits in mild tension with a tool that fetches arbitrary public https hosts, and the description does not address that tension. Rich but partly redundant with the many disclaimers.

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

Conciseness3/5

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

Front-loads the core question well, but the disclaimers are piled up ('NOT who the operator is in law, NOT legal identity, NOT safety... Not a certification and not a guarantee'), repeating the same non-guarantee several times. Operational limits and trust caveats are interleaved rather than grouped, making the block longer than it needs to be.

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?

With no output schema, the description still tells the agent the return vocabulary (matches, does_not_match, cannot_tell), that every check is listed and the result is LLPRO-signed with the observation time. For a 3-parameter, nested-object, no-required-args tool, nothing an agent needs in order to call it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, and the description earns an increment by explaining the semantics of the outcome that the challenge produces: a key a card only names, without proof, yields cannot_tell, which tells an agent why to bother supplying a challenge. It also names the well-known paths tried for a domain, which complements the schema's shorter note.

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?

Names a specific three-way check: card vs. serving domain vs. published keys, and frames it as a question an agent can answer ('Does this agent's card agree with the domain that served it and the keys that domain publishes?'). It also explicitly delimits scope ('Shows control of a domain, not who the operator is in law'), which makes it easy to separate from card-only checks like agent_card_check.

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

Usage Guidelines4/5

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

Gives real usage context ('Feeds Identity and payment rails: one input to a decision to deal with an agent, never the whole decision') plus hard preconditions (public https hosts, port 443, ASCII names, card size, 4 fetches). It never explicitly says 'use agent_card_check instead when you only have a card', so routing between siblings is left to inference, but the when-to-use framing is otherwise strong.

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

All LLPRO Campus tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?