Shodai Agreements
REMOTE · SHODAI.NETWORK · SCANNED SEP 20
Author, validate, deploy, and operate Shodai on-chain agreements.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security97
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- The endpoint enforces authorisation, advertised via RFC 9728 protected-resource metadata. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism. View diagnostics → Pass
Transport & Reachability0
- Transport blocked by authentication: the endpoint requires auth we don't have to verify streamable-http. See how to fix → View diagnostics → Unverified
Schema Quality & AI Usability0
- Schema blocked by authentication: the endpoint requires auth we don't have to read it. See how to fix → Unverified
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
- Tool coverage blocked by authentication: the endpoint requires auth we don't have to read its tools.Unverified
Tool Safety0
- Tool safety blocked by authentication: the endpoint requires auth we don't have to read its tools.Unverified
Capabilities0
- Capabilities blocked by authentication: the endpoint requires auth we don't have to read them. See how to fix → Unverified
Unverified: 6 categories
Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm. Claim this server and supply a read-only token to verify it and lift the score.
How do I install the Shodai Agreements MCP server?
Shodai Agreements is a hosted endpoint at https://shodai.network/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · shodai.network
claude mcp add --transport http network-shodai-agreements 'https://shodai.network/mcp'
{
"mcpServers": {
"network-shodai-agreements": {
"url": "https://shodai.network/mcp"
}
}
} {
"servers": {
"network-shodai-agreements": {
"type": "http",
"url": "https://shodai.network/mcp"
}
}
} [mcp_servers.network-shodai-agreements] url = "https://shodai.network/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"network-shodai-agreements": {
"type": "remote",
"url": "https://shodai.network/mcp",
"enabled": true
}
}
} openclaw mcp add network-shodai-agreements --url 'https://shodai.network/mcp' --transport streamable-http
mcp_servers:
network-shodai-agreements:
url: "https://shodai.network/mcp" {
"McpServers": {
"network-shodai-agreements": {
"Transport": "http",
"Url": "https://shodai.network/mcp"
}
}
} assistant mcp add network-shodai-agreements -t streamable-http -u 'https://shodai.network/mcp'
{
"mcpServers": {
"network-shodai-agreements": {
"type": "http",
"url": "https://shodai.network/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 26 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 11 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 8 Aug 26 0
- Authorization: fail → pass ▲ security
- First check of Authorization: pass security
- 6 Aug 26 0
- Endpoint reachability: reachable → behind authorisation ▼ security
- Stability: 0.33 → unverified ▼ security
- Transport: pass → unverified ▼ security
- Authorization: The endpoint enforces authorisation, but returns a challenge with no valid RFC 9728 metadata, so a client cannot discover where to get a token. security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Schema quality: 100 → unverified ▼ functional
- 31 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 0
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Probed https://shodai.network/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=shodai.network | CN=YR2,O=Let's Encrypt,C=US | 12 Sept 2026 | 11 Dec 2026 | RSA 2048 | SHA256-RSA | 53b91666dbbafa546e18c785138e86007f8 |
| SANs: shodai.network | ||||||
| CN=YR2,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | 4ebd24947e24d394802d84a52fd5b319 |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of shodai.network. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| network. | present | 40414 | 8 | Verified |
| shodai.network. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On connection |
| HTTP status | 401 |
WWW-Authenticate challenge Bearer realm="mcp", resource_metadata="https://shodai.network/.well-known/oauth-protected-resource", scope="agreements.read agreements.write webhooks.read webhooks.write"
Bearer realm="mcp", resource_metadata="https://shodai.network/.well-known/oauth-protected-resource", scope="agreements.read agreements.write webhooks.read webhooks.write"| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000 |
| www-authenticate | Bearer realm="mcp", resource_metadata="https://shodai.network/.well-known/oauth-protected-resource", scope="agreements.read agreements.write webhooks.read webhooks.write" |
Protected resource metadata
| Document | https://shodai.network/.well-known/oauth-protected-resource |
|---|---|
| Retrieved | Yes |
| Resource | https://shodai.network/mcp |
| Authorisation server | https://testnet.shodai.network/auth-api |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://shodai.network/mcp | Auth required | 401 | |
| http (plaintext) | http://shodai.network/mcp | HTTPS enforced | 308 | https://shodai.network/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
deploy_agreement Deploy agreement ~346
Deploys authored agreement JSON using an EIP-712 permit; the API submits the on-chain transaction and returns the deployed agreement record. Provide a pre-signed permit (signer, deadline, signature), or call prepare_deployment_typed_data first to obtain the payload to sign. Always run preflight_deployment before deploying. Requires the agreements.write scope.
| Name | Type | Req | Description |
|---|---|---|---|
| agreement | object | yes | Complete authored agreement JSON document with metadata, variables, content, and execution sections. |
| chainId | integer | – | Target EVM chain ID (e.g. 59141 for Linea Sepolia). |
| deadline | integer | – | Permit deadline in unix seconds. Must match the signed payload. |
| displayName | string | yes | Human-readable name for the deployed agreement record. |
| docUri | string | – | Optional document URI recorded on-chain with the agreement. |
| documentId | string | – | Optional hosted document ID paired with docUri for GET /v0/agreements/documents/{documentId}. |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
| initValues | object | – | Deployment-time values for variables referenced by execution.initialize.data. |
| observers | array | – | Observer email addresses. |
| participants | array | – | Wallet mappings for participant variables. |
| signatureR | string | – | Permit signature r component (0x... 32 bytes). |
| signatureS | string | – | Permit signature s component (0x... 32 bytes). |
| signatureV | integer | – | Permit signature v component (27 or 28). |
| signer | string | – | Wallet address (0x...) that signed the permit. |
No output schema declared.
No examples provided.
get_agreement Get agreement ~85
Returns a single agreement record, including the full authored agreement JSON and hosted record context (participants, observers, owner, deployment address).
| Name | Type | Req | Description |
|---|---|---|---|
| agreementId | string | yes | Agreement record ID, as returned by list_agreements (not the on-chain address). |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
No output schema declared.
No examples provided.
get_agreement_document Get agreement document ~114
Returns the rendered hosted prose document for an agreement by documentId, including content type, display name, chain, docUri, and agreement record references. Use documentId from list_agreements/get_agreement or from prepare_deployment_typed_data.
| Name | Type | Req | Description |
|---|---|---|---|
| documentId | string | yes | Hosted agreement document ID, as returned by list_agreements/get_agreement or prepare_deployment_typed_data. |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
No output schema declared.
No examples provided.
get_agreement_state Get agreement state ~99
Returns the current state of an agreement. For deployed agreements, interpret the state against the states defined in the authored agreement lifecycle (execution.states). Use this to poll for transitions after submitting an input.
| Name | Type | Req | Description |
|---|---|---|---|
| agreementId | string | yes | Agreement record ID, as returned by list_agreements (not the on-chain address). |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
No output schema declared.
No examples provided.
get_input_history Get input history ~159
Returns recorded input submissions for an agreement, with pagination and filtering. Use this to inspect which events have been submitted and whether each is PENDING, MINED, or FAILED.
| Name | Type | Req | Description |
|---|---|---|---|
| agreementId | string | yes | Agreement record ID, as returned by list_agreements (not the on-chain address). |
| cursor | string | – | Opaque pagination cursor from a previous response (pageInfo.nextCursor). |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
| inputId | string | – | Filter by input ID as defined in the agreement JSON (execution.inputs). |
| limit | integer | – | Page size (max 100). |
| status | string | – | Filter by submission status. |
No output schema declared.
No examples provided.
list_agreements List agreements ~262
Lists agreement summaries visible to the current API key. Supports pagination (cursor + limit), filtering by chain and state, and sorting. Returns summaries only; use get_agreement for the full record.
| Name | Type | Req | Description |
|---|---|---|---|
| chainId | integer | – | Filter by EVM chain ID (e.g. 59141 for Linea Sepolia). |
| createdAfter | string | – | ISO 8601 timestamp; only agreements created at or after this time. |
| createdBefore | string | – | ISO 8601 timestamp; only agreements created at or before this time. |
| cursor | string | – | Opaque pagination cursor from a previous response (pageInfo.nextCursor). |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
| limit | integer | – | Page size (max 100). |
| sortBy | string | – | Sort field (single field only). |
| sortDirection | string | – | Sort direction; defaults to desc. |
| state | string | – | Filter by current lifecycle state ID. |
| updatedAfter | string | – | ISO 8601 timestamp; only agreements updated at or after this time. |
| updatedBefore | string | – | ISO 8601 timestamp; only agreements updated at or before this time. |
No output schema declared.
No examples provided.
preflight_deployment Preflight deployment request ~181
Checks whether authored agreement JSON plus target chain, deployment values, participant wallet mappings, and observer context are ready for deployment. This does not deploy the agreement and does not require a signature. Always run this before signing a deploy permit. Requires the agreements.write scope.
| Name | Type | Req | Description |
|---|---|---|---|
| agreement | object | yes | Complete authored agreement JSON document with metadata, variables, content, and execution sections. See the simple/complex example resources for the authoritative shape. |
| chainId | integer | – | Target EVM chain ID for deployment. |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
| initValues | object | – | Deployment-time values for variables referenced by execution.initialize.data. |
| observers | array | – | Observer email addresses for the deployed agreement. |
| participants | array | – | Wallet mappings for participant variables. |
No output schema declared.
No examples provided.
prepare_deployment_typed_data Prepare deployment permit typed data ~299
Builds the exact EIP-712 payload that must be signed to authorize deployment of the given agreement JSON. Sign the returned typedData with the deploying wallet (eth_signTypedData_v4 / viem signTypedData), then call deploy_agreement with signer, deadline, and the signature components. No transaction is sent and nothing is stored. Reads the signer nonce from the target chain.
| Name | Type | Req | Description |
|---|---|---|---|
| agreement | object | yes | Complete authored agreement JSON document with metadata, variables, content, and execution sections. |
| chainId | integer | yes | Target EVM chain ID (e.g. 59141 for Linea Sepolia). |
| deadline | integer | – | Permit deadline in unix seconds; defaults to one hour from now. |
| docUri | string | – | Document URI (must match the later deploy_agreement call). |
| documentId | string | – | Hosted document ID. If omitted with docUri, no hosted document ID is stored; if both are omitted, the server generates both values. |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
| initValues | object | – | Deployment-time init values (must match the later deploy_agreement call). |
| observers | array | – | Observer email addresses. |
| participants | array | – | Wallet mappings for participant variables. |
| signerAddress | string | yes | Wallet address (0x...) that will sign and own the deployment. |
No output schema declared.
No examples provided.
prepare_input_typed_data Prepare input permit typed data ~196
Builds the exact EIP-712 payload that must be signed to authorize submitting an input to a deployed agreement. Sign the returned typedData with a wallet allowed by the input definition, then call submit_input with signer, deadline, and the signature components. No transaction is sent and nothing is stored. Reads the agreement record and signer nonce.
| Name | Type | Req | Description |
|---|---|---|---|
| agreementId | string | yes | Agreement record ID of a deployed agreement. |
| deadline | integer | – | Permit deadline in unix seconds; defaults to one hour from now. |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
| inputId | string | yes | Input ID defined by the agreement JSON (execution.inputs). |
| signerAddress | string | yes | Wallet address (0x...) that will sign the input permit. |
| values | object | yes | Values matching the input schema (must match the later submit_input call). |
No output schema declared.
No examples provided.
submit_input Submit input with permit ~244
Submits a signed input to a deployed agreement, advancing its on-chain lifecycle. The input ID and values must match an input defined by the agreement JSON, and the signer must be allowed by that input. Provide a pre-signed permit (signer, deadline, signature), or call prepare_input_typed_data first. Requires the agreements.write scope.
| Name | Type | Req | Description |
|---|---|---|---|
| agreementId | string | yes | Agreement record ID of a deployed agreement. |
| deadline | integer | – | Permit deadline in unix seconds. Must match the signed payload. |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
| inputId | string | yes | Input ID defined by the agreement JSON (execution.inputs). |
| signatureR | string | – | Permit signature r component (0x... 32 bytes). |
| signatureS | string | – | Permit signature s component (0x... 32 bytes). |
| signatureV | integer | – | Permit signature v component (27 or 28). |
| signer | string | – | Wallet address (0x...) that signed the permit. |
| values | object | yes | Values matching the input schema defined by the agreement JSON. |
No output schema declared.
No examples provided.
validate_agreement Validate agreement structure ~134
Checks only the authored agreement JSON document and returns participant variable keys, input IDs, state IDs, and warnings. This does not validate deployment values, participant wallet addresses, signer, or permit data — use preflight_deployment for that. Iterate on the agreement JSON until this returns no blocking warnings. Requires the agreements.write scope.
| Name | Type | Req | Description |
|---|---|---|---|
| agreement | object | yes | Complete authored agreement JSON document with metadata, variables, content, and execution sections. See the simple/complex example resources for the authoritative shape. |
| environment | string | yes | Agreements API environment for this tool call. API keys only work in the environment where they were created. |
No output schema declared.
No examples provided.
What is the Shodai Agreements MCP server?
Shodai Agreements is an MCP server listed in the public MCP registry as network.shodai/agreements. Author, validate, deploy, and operate Shodai on-chain agreements. This page covers its hosted endpoint (https://shodai.network/mcp).
Is the Shodai Agreements MCP server safe to use?
Shodai Agreements scores 39 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Shodai Agreements MCP server expose?
Shodai Agreements exposes 11 tools: list_agreements, get_agreement, get_agreement_document, get_agreement_state, get_input_history, and 6 more. Their descriptions and schemas cost roughly 2,119 tokens of context every time the server is loaded.
Does the Shodai Agreements MCP server require authentication?
Yes. Shodai Agreements asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Shodai Agreements MCP server still maintained?
Shodai Agreements is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.