xrpl-did-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| XRPL_MCP_NETWORK | No | The XRPL network to use (e.g. "testnet" or "mainnet"). Testnet is the default; mainnet is the same code with network="mainnet". | testnet |
| XRPL_MCP_KEYCHAIN_SERVICE | No | The OS keychain service name from which the server reads the signing seed. Defaults to "xrpl-did-mcp". | xrpl-did-mcp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| derive_didA | Derive the W3C-compatible decentralized identifier for an account on the XRP Ledger. Format: did:xrpl::. This is a pure derivation -- no transaction, no registration, no fee. |
| resolve_didA | Resolve a did:xrpl into its DID Document by reading the XRP Ledger. The document is fetched from the ledger itself, so the result is verifiable by anyone and does not depend on this server. This is the only tool that returns a DID Document. For an account's balance and other on-ledger state, use lookup_account. |
| check_authorizationA | Evaluate an agent against a trust policy and return an allow/deny decision with the reasons. The result reports which required credentials are missing and which deny rules matched, so the decision is auditable rather than a bare boolean. The caller's policy is combined with the server operator's policy file, if one is configured. The operator's deny and ban rules are applied on top of the caller's and cannot be waived by them. |
| publish_did_setA | Submit a DIDSet transaction so the agent's DID resolves to a DID Document. THIS WRITES TO THE LEDGER and spends XRP. The signing seed comes from the OS keychain, which the server reads itself, so the agent never sees the seed. This tool is only available if the server was started with --allow-writes. An optional Defaults to testnet; pass network='mainnet' explicitly to use mainnet. |
| revoke_didA | Submit a DIDDelete transaction, removing the account's DID Document from the ledger so the DID no longer resolves. THIS WRITES TO THE LEDGER and spends XRP. DIDDelete takes only common fields -- it always deletes the signer's own DID, so the address must match the account the seed controls. This does NOT delete the account's credentials. A DID and a credential are separate ledger objects, and rippled's DIDDelete erases only the DID. To withdraw an authorization, revoke the credential too. This tool is only available if the server was started with --allow-writes. The signing seed comes from the OS keychain, which the server reads itself, so the seed never passes through the agent's context. |
| revoke_credentialA | Submit a CredentialDelete transaction, withdrawing one credential so it no longer counts as held. THIS WRITES TO THE LEDGER and spends XRP. A credential is identified by the triple (issuer, subject, credential_type). The issuer or the subject may sign the delete. This tool is only available if the server was started with --allow-writes. The signing seed comes from the OS keychain, which the server reads itself, so the seed never passes through the agent's context. |
| issue_credentialA | Create a credential on the XRP Ledger, so a subject can be authorised to act. THIS WRITES TO THE LEDGER and spends XRP. The signing seed comes from the OS keychain, which the server reads itself, so the agent never sees the seed. This tool is only available if the server was started with --allow-writes. An optional The credential is created but not yet valid for the subject until the subject accepts it with accept_credential. To withdraw a credential, use revoke_credential instead. To read a credential's state without changing anything, use get_credential. |
| accept_credentialA | Accept a credential that was issued to this account, making it valid for the subject. THIS WRITES TO THE LEDGER and spends XRP. A credential created with issue_credential is not valid for the subject until the subject signs it. This tool is the subject's side of that: it submits the CredentialAccept. The signing seed comes from the OS keychain, which the server reads itself, so the agent never sees the seed. This tool is only available if the server was started with --allow-writes. An optional To read a credential's state without changing anything, use get_credential. To withdraw a credential, use revoke_credential. |
| get_credentialA | Read one credential's state from the XRP Ledger: whether it exists, whether the subject has accepted it, its URI, and its expiration. This is a pure read. It submits no transaction, spends nothing, and does not need --allow-writes. Existence is not acceptance: a credential issued with issue_credential does not become valid for the subject until the subject accepts it. This tool reports which of those is true. For an account's balance and other state, use lookup_account. To accept a credential, use accept_credential. |
| lookup_accountA | Read an XRP Ledger account's on-ledger state: its balance in drops, the number of objects it owns, and its next transaction sequence. For an account's DID Document, use resolve_did instead -- that tool returns the document itself, not the account's other state. |
| lookup_transactionA | Read a transaction's outcome from the XRP Ledger by its hash: the result code (for example tesSUCCESS for a successful transaction, or tecUNFUNDED_PAYMENT for one that failed), the ledger index it was included in, and whether it has been validated. For the account that sent or received it, use lookup_account. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool has a distinct purpose: DID derivation, DID publishing/resolution/deletion, credential issuance/acceptance/read/revocation, account/transaction lookup, and policy authorization are all clearly separated. The descriptions explicitly cross-reference neighboring tools to prevent confusion between pure reads, writes, and derivations.
All tools use snake_case and a verb-first pattern, such as derive_did, issue_credential, lookup_account, resolve_did, and revoke_credential. The naming is predictable and stable across the whole set.
Eleven tools is well scoped for XRPL DID and credential operations. Each tool maps to a meaningful operation, and there is no obvious filler or redundant tool.
The core lifecycle is covered: DID derivation, publishing, resolution, and deletion; credential issuance, acceptance, reading, and revocation; plus account/transaction lookup and authorization checks. A minor gap is the lack of a credential listing/discovery operation, which could make it harder to enumerate credentials without already knowing the issuer, subject, and type.