Neutral witness for agent-to-agent sessions: signed, hash-chained, verifiable records.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 8 tools
Each tool targets a distinct phase of the session lifecycle: registration, offer, acceptance, messaging, closing, retrieval, and verification. The only overlap (start_session vs invite_counterparty) is explicitly differentiated as a convenience wrapper with a clear recommendation to use one over the other.
All tool names follow a consistent verb_noun pattern (accept_invite, close_session, get_record, etc.), making the action and target immediately clear. No stylistic deviations or ambiguous verbs.
8 tools is well-scoped for a witnessed session service, covering the core lifecycle without unnecessary bloat or missing essentials. Each tool has a clear purpose and contributes to the workflow.
The tool set covers registration, invitation/acceptance, messaging, closing, record retrieval, and verification. A minor gap is the lack of a dedicated get_session tool, but send_message's prepare mode provides session state, and get_record handles closed sessions, so agents can work around this without failure.
The other half of start_session/invite_counterparty: accept an invite addressed to you (direct) or bearer a token for (open). mode: "prepare" (auth = a signed GET of the invite; pass token for open invites) returns the offer and its offerHash so you know exactly what to build and sign next. mode: "submit" (auth = a signed POST) then submits your signed Accept (SPEC §7.2, purpose "accept"), which activates the session. Before accepting, consider calling verify_agent with the initiator's agentId to confirm they're a real, active, claimed agent — the prepare response includes their public profile for exactly this.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | Yes | ||
| mode | Yes | ||
| token | No | Required for open invites (bearer token from the invite URL). | |
| accept | No | Required for mode=submit. | |
| inviteId | Yes | ||
| signature | No | Required for mode=submit — the accept signature, not the request auth. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and largely meets it: it discloses that prepare returns the offer and offerHash, that submit sends a signed Accept and 'activates the session', and that auth is a signed GET vs signed POST depending on mode. It does not detail failure behavior or what the submit response contains, but the main side effects and sequencing are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loads the tool's role before explaining the two modes. The final verify_agent sentence is useful guidance rather than fluff, though the long mid-sentence parenthetical makes it slightly harder to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 6-parameter tool with nested objects, no output schema, and no annotations, the description covers the essential decision sequence: inspect with prepare, sign the correct object, submit with a signed POST, and optionally verify the counterparty first. It could be more explicit about the inviteId source and submit response, but an agent has enough to proceed correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, but the description adds real meaning beyond the schema: it explains mode=prepare vs mode=submit, when token is required for open invites, how auth differs between modes, and that offerHash should be signed. Some parameters like inviteId are still only inferred from the tool name, but the core execution flow is clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by naming the resource ('accept an invite') and explicitly positions it as 'the other half of start_session/invite_counterparty', differentiating it from sibling tools. It distinguishes direct vs open invites and names the two modes, so an agent knows exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use prepare to inspect the offer/hash before building the Accept, then submit to activate the session. It also recommends verify_agent as a pre-acceptance validation step with the initiator's agentId, though it does not explicitly state when to avoid this tool in favor of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close an active session (POST /v1/sessions/{id}/close), which starts record issuance — the platform builds the evidence bundle, signs a record, and both owners can retrieve it afterward. mode: "prepare" (auth = a signed GET) returns the current head to close at. mode: "submit" (auth = a signed POST) submits your signed CloseStatement, built per SPEC §7.4.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | Yes | ||
| mode | Yes | ||
| sessionId | Yes | ||
| signature | No | Required for mode=submit. | |
| statement | No | Required for mode=submit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, and it does this well: it states that closing is not merely a state change but triggers evidence-bundle construction, record signing, and later retrieval by both owners. It also discloses that auth must be signed locally per request mode and that the server cannot compute signatures. It stops short of stating whether closing is irreversible or idempotent, which would be useful, but the major side effects are clearly surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full payload: purpose, endpoint, side effects, mode distinction, auth style, and spec reference. Every clause adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested, mode-dependent tool with no output schema and no annotations, the description covers the why and the side effects well, but it leaves gaps: what a successful submit returns, how to construct the CloseStatement beyond a spec reference, and whether the operation can be retried or reversed. The prepare-mode return is described, but the submit-mode response is not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description must compensate, and it partly does: it clarifies that mode=prepare returns the current head and mode=submit sends a signed CloseStatement, which adds meaning beyond the bare enum. However, it does not add useful semantics for sessionId or the separate signature object, and the relationship between auth, signature, and statement could be clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with an explicit verb and resource—'Close an active session'—and names the exact endpoint (POST /v1/sessions/{id}/close), so an agent immediately knows what action this tool performs. It also states the consequence ('starts record issuance, the platform builds the evidence bundle, signs a record'), which makes the purpose concrete and distinguishes it from sibling tools like start_session or get_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use this for an active, witnessed session, and it explains when to use each mode—prepare returns the current head, submit sends the signed CloseStatement. It does not explicitly name alternatives or state when-not-to-use conditions, but the mode-level guidance and the requirement that the session be active are strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the signed record for a closed session (GET /v1/records/{id}, or the full downloadable verification bundle with bundle: true). Only the two participant agents and their owners can read a record. If you don't have the recordId, read it off the session (GET-via-send_message's prepare mode returns the session, which includes recordId once status is "closed").
| Name | Required | Description | Default |
|---|---|---|---|
| auth | Yes | ||
| bundle | No | Set true to get the full verifiable bundle instead of the summary. | |
| recordId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the access-control restriction, the closed-session requirement, and the two output modes (signed record summary vs. full downloadable bundle). It does not describe error behavior for unauthorized or unclosed sessions, but the core behavioral contract is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the key action and constraint are front-loaded, and the recordId fallback is a separate, well-placed clarification. It is slightly dense with nested references, but every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-purpose read tool with no output schema, the description covers what is returned, when it is available, who may call it, and how to get the required ID if missing. Missing details like explicit error codes are minor; the description is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% because recordId has no schema description, so the description adds crucial meaning by explaining how to obtain recordId and that it must belong to a closed session. It also clarifies the bundle parameter as 'full downloadable verification bundle' vs. the summary. The auth parameter is left to the schema, which already documents it thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Fetch the signed record for a closed session,' and even names the HTTP endpoint and the optional bundle mode. This makes the tool's purpose unmistakable and clearly distinct from siblings like send_message or verify_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the only precondition (session must be closed) and provides a fallback path when recordId is missing: read it off the session via send_message's prepare mode. It does not explicitly list exclusion conditions, but the closed-session constraint and the access restriction ('only the two participant agents and their owners') give clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convenience wrapper around start_session for the common case: you already know the other agent's id and want to offer them a session directly. Does a pre-flight GET /v1/agents/{id} check (that the counterparty exists and is active) before submitting the offer, so you get a clear error instead of a session nobody can ever accept. offer.counterparty must be set (not an open invite — use start_session for that). Same signing requirements as start_session: you build and sign the offer yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | Yes | ||
| offer | Yes | ||
| offerSignature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the pre-flight GET /v1/agents/{id} check, the requirement that offer.counterparty be set, and the signing requirements (same as start_session). It does not mention side effects or reversibility, but for a session-offer tool that is likely acceptable; it is transparent about the essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are dense and front-loaded. The purpose is stated first, usage guidance and behavioral notes follow efficiently. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (nested objects, signing, pre-flight) and has no output schema. The description does not mention the response format or error cases beyond 'clear error'. It covers the key decision factors and pre-flight, but an agent might need more on what to expect after a successful call. Given the complexity, a bit more detail on return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for offer.counterparty (must be set) and the signing process, but does not explain the auth object, offerSignature, or other offer fields. The schema itself has detailed descriptions for auth properties, so the agent can get details there, but the description only partially covers the parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (invite) and resource (known counterparty to a session), and explicitly differentiates itself as a convenience wrapper around start_session. The first sentence makes it clear what it does and how it differs from the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (you already know the other agent's id) and when not (use start_session for open invites). Also explains the pre-flight check that improves error clarity, giving the agent a clear decision path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register yourself as a new OpenGlass agent. Use this once, the first time you want to run a witnessed session with another agent — OpenGlass is a neutral third party that hash-chains, signs, and countersigns every message in a session so both sides' human owners get an independently verifiable record afterward. Before calling this: generate your own Ed25519 keypair locally (never send the private key anywhere, including to this tool) and sign this request yourself (SPEC §4.1) using that key, with auth.kid set to the literal "new" — the server verifies the signature against the publicKey you're registering, proving you hold it. The response includes a claim URL: show it to your human owner so they can claim you — you can't start a session until you're claimed (poll verify_agent with your own agentId, or just retry start_session, which returns agent_unclaimed until then).
| Name | Required | Description | Default |
|---|---|---|---|
| auth | Yes | ||
| meta | No | ||
| name | Yes | A human-readable name for this agent. | |
| publicKey | Yes | Your Ed25519 public key, base64url-encoded (43 chars, no padding). | |
| description | Yes | What this agent does, for its public profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does so thoroughly: it discloses that the server verifies the signature against the submitted publicKey, that the response includes a claim URL, that no session can start until claimed, and that start_session returns agent_unclaimed until then.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core purpose, and every clause adds useful information for a complex authentication flow. It could be slightly more scannable with structured bullets, but it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested auth parameters and no output schema, the description covers the request flow, response hint (claim URL), and post-registration behavior well. Minor gaps remain around where the agentId comes from and the full response shape, but the essential calling sequence is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, and the description adds critical meaning beyond the schema, especially around auth: the literal 'new' value for kid, the signature computation, and the publicKey ownership proof. It does not discuss meta or the name/description fields, but those are already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action and resource: 'Register yourself as a new OpenGlass agent.' It also clarifies that this is a one-time setup step preceding witnessed sessions, which distinguishes it from the session-operation siblings like start_session and send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this once, the first time...' and lays out concrete preconditions: generate a keypair, sign the request, and set auth.kid to 'new'. It also routes follow-up behavior to verify_agent or start_session, giving clear alternative choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a signed, hash-chained message to an active session (POST /v1/sessions/{id}/messages). Two modes: mode: "prepare" (auth = a signed GET of the session) returns the current head (seq/prevHash) so you know exactly what to build and sign next — always do this first unless you're already certain of the head, since a stale seq/prevHash is rejected with chain_conflict. mode: "submit" (auth = a signed POST) then appends your envelope/hash/signature/payload. Build the envelope, its hash, and its signature yourself per SPEC §7.3 — this tool only relays them.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | Yes | ||
| hash | No | Required for mode=submit. | |
| mode | Yes | ||
| payload | No | Required for mode=submit in relay-mode sessions; must be omitted in notary mode. | |
| envelope | No | Required for mode=submit. | |
| sessionId | Yes | ||
| signature | No | Required for mode=submit — the message signature, not the request auth. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool only relays caller-built artifacts, that prepare returns the current head, and that stale seq/prevHash triggers chain_conflict. It does not explicitly describe the submit response or state that the append is permanent, but the core behavior is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load the operation and endpoint, then organize the two modes and their sequence. Every clause earns its place, including the failure-mode warning and the relay-only clarification, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, two-mode tool with nested objects, no annotations, and no output schema, the description covers the essential workflow, auth requirements, and error condition. The main gaps are the lack of a submit response format and the unexplained notary vs relay-mode distinction that appears only in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 57%, so the description adds necessary meaning by explaining mode semantics, the auth requirements for prepare vs submit, and that envelope/hash/signature/payload must be constructed by the caller. The schema already documents many fields, and the description fills the critical workflow gaps rather than repeating schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Append a signed, hash-chained message to an active session' and provides the exact endpoint. This clearly differentiates send_message from lifecycle siblings like start_session and close_session, despite the title being more abstract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit mode-level guidance: always run prepare first unless certain of the head, because a stale head is rejected with chain_conflict. It also explains what each mode is for and the sequence between them, leaving no ambiguity about how to invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offer a witnessed session to another agent (POST /v1/sessions). You must be claimed already (see register_agent). Build and sign the offer yourself (SPEC §7.2, purpose "offer") — this tool only relays it. Set offer.counterparty to a known agentId for a direct invite, or omit it (null) for an open, bearer-token invite anyone with the link can accept. If you already know the counterparty's agentId, prefer invite_counterparty instead — it does the same thing plus a pre-flight check that the agent actually exists and is active, so you don't offer a session into the void.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | Yes | ||
| offer | Yes | ||
| offerSignature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool only relays the offer (does not build/sign it), that the caller must build/sign it themselves, that counterparty can be null for an open bearer-token invite, and that the invite can be accepted by anyone with the link. It also explains the auth requirement (server cannot compute signatures). These are significant behavioral disclosures beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized. It front-loads the core action, then prerequisites, then the key decision (counterparty vs null), then the sibling alternative. Every sentence earns its place. It could be slightly more compact, but the density is justified given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, signing requirements, no output schema, no annotations), the description covers the essential operational context: what the tool does, what the caller must do beforehand, how to choose counterparty mode, and how to choose between this and the sibling tool. The reference to SPEC §7.2 fills any remaining gap about offer construction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the semantics of the offer object (build/sign it yourself), the counterparty field (set to agentId for direct invite, null for open invite), and the auth object (server cannot compute signatures). It doesn't explicitly explain offerSignature but the spec reference and auth discussion cover the signing context. This is strong compensation for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Offer a witnessed session'), the resource (POST /v1/sessions), and the target audience ('to another agent'). It also distinguishes itself from the sibling invite_counterparty by explicitly naming it and describing the difference (pre-flight check). The mention of SPEC §7.2 adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it states the prerequisite ('You must be claimed already — see register_agent'), gives a conditional rule ('If you already know the counterparty's agentId, prefer invite_counterparty instead'), and explains why (avoids offering into the void). This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two independent checks, pick one: pass agentId to look up a counterparty's public profile before trusting them (confirms they're registered and claimed — do this before accepting an invite from someone you don't already know). Or pass bundle (a full record bundle, e.g. from get_record with bundle=true) to independently re-run the full cryptographic verification (SPEC §7.6) against OpenGlass's own trusted platform keys — this is a public check, no signing required, and is exactly what a court or auditor could run themselves without trusting OpenGlass's word for it.
| Name | Required | Description | Default |
|---|---|---|---|
| bundle | No | ||
| agentId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose important traits: the check is public, requires no signing, and is independent of OpenGlass's own assertions. However, it does not state what the tool returns, whether there are side effects, or how it behaves if both or neither parameter is passed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the essential contract and every clause adds operational or trust-relevant value. It is relatively long, but the dual-mode complexity justifies the length and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong on intent, input origin, and trust context, but with no output schema and no annotations it omits return-value semantics and the both/neither handling for the two optional parameters. A caller would still need to discover what a successful verification result looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description defines both parameters meaningfully: agentId identifies a counterparty for a public-profile check, and bundle is a full record bundle such as one from get_record with bundle=true. This goes well beyond the bare property names, though mutual exclusivity is only implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the core contract—'two independent checks, pick one'—and clearly names both resources: a counterparty public profile and a record bundle. The verb 'verify' plus the concrete operations (lookup/confirm vs. re-run cryptographic verification) make the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: use the agentId mode before accepting an invite from an unknown counterparty, and use the bundle mode for independent cryptographic verification. It also references get_record with bundle=true as the source for the bundle input, effectively routing the agent to the right alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
accept_inviteclose_sessionget_recordinvite_counterpartyregister_agentsend_messagestart_sessionverify_agentIssue & verify signed (ed25519), hash-chained, timestamped provenance receipts for agent actions.
Tamper-evident audit log service for agent-to-agent transactions
Verified memory for AI agents. Signed assertions, billing attestation, session continuity.
Immutable event logging and audit trail for agent transactions
Add one secure layer between your agents and this server.