Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
XRPL_MCP_NETWORKNoThe 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_SERVICENoThe 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 seed argument exists for throwaway testnet use. It is refused unless the server was started with --allow-inline-seed, because a seed in the agent's context is a seed the agent can read.

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 seed argument exists for throwaway testnet use. It is refused unless the server was started with --allow-inline-seed, because a seed in the agent's context is a seed the agent can read.

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 seed argument exists for throwaway testnet use. It is refused unless the server was started with --allow-inline-seed.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 11 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessResponsive