xrpl-did-mcp

Decide whether an agent is authorized to act

check_authorization

Evaluates an agent's credentials against a trust policy and returns an auditable allow/deny decision, including missing credentials and matched deny rules.

Instructions

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.

Input Schema

Name	Required	Description	Default
`network`	No
`agent_did`	Yes
`banned_agents`	No
`denied_issuers`	No
`credential_type`	Yes
`trusted_issuers`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.4.0Oct 29, 2026

addedInput schema / properties / banned_agents

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Banned Agents"
+}

addedInput schema / properties / denied_issuers

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Denied Issuers"
+}

First observedv0.2.0Oct 28, 2026

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the return shape (allow/deny with reasons, missing credentials, matched deny rules) and the important policy-layering behavior. It explains that operator deny/ban rules are applied on top of caller rules and cannot be waived, which is exactly the kind of non-obvious behavior an agent needs. It does not state whether the check is purely read-only or whether it has side effects such as logging.

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

Conciseness5/5

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

Two tight paragraphs, front-loaded with the decision outcome and followed by the most consequential policy-layering caveat. Every sentence adds useful information with no repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values in full, and its behavioral policy notes are strong. However, with six undocumented input parameters at 0% schema coverage, the definition is incomplete about what each input controls, which is a material gap for an authorization decision tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across six parameters, so the description must compensate. It mentions 'required credentials' and 'deny rules' only abstractly and never maps meaning to agent_did, trusted_issuers, credential_type, banned_agents, denied_issuers, or network. An agent must infer parameter semantics entirely from names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: evaluate an agent against a trust policy and return an allow/deny decision with reasons. This is clearly distinct from the DID/credential-management siblings, though it does not explicitly name or differentiate itself from them.

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

Usage Guidelines3/5

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

Usage is implied by 'evaluate an agent against a trust policy' and the auditability framing, but the description never says when to call this versus alternatives, nor when not to call it. For a gatekeeping decision tool, this is adequate but leaves timing and prerequisites to inference.

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

Deploy Server