
Shodai Agreements
network.shodaiPublished by shodai.networkOfficial publisherv0.1.0Updated Nov 2, 2026
Author, validate, deploy, and operate Shodai on-chain agreements.
Overview
Shodai Agreements lets an assistant author, validate, preflight, deploy and operate on-chain agreements through the Shodai Agreements API.
- What you can do
- List, read and inspect agreements, their documents, state and input history
- Validate agreement templates and preflight deployments before committing
- Deploy agreements and submit inputs, using pre-signed EIP-712 permits
- Prepare EIP-712 typed data for deployments and inputs so a wallet can sign externally
- Read bundled example agreements, an authoring guide and a docs index as resources
- Use an author_agreement prompt to turn a business description into agreement JSON
- When to use it
- Useful when you work with Shodai on-chain agreements and want an assistant to draft, check and deploy them, or to prepare signing payloads for an external wallet. It fits testnet experimentation and production agreement operations through the hosted endpoint.
- Requirements
- Remote Streamable HTTP endpoint at shodai.network/mcp, or the npm package run locally over stdio with Node.js. Authentication is required: OAuth browser sign-in, or an API key sent as an Authorization bearer header (AGREEMENTS_API_KEY locally). Local mode also accepts OAuth client credentials, an environment setting (testnet or production), and optional INFURA_PROJECT_ID or RPC URL overrides.
Installation
In SourceWeft
- Open Shodai Agreements in the dashboard and add it to a workspace.
- Connect the required credentials. They are stored privately and never shown on public pages.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Use with an agent
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/network.shodai%2Fagreements/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Other MCP clients
Add this to your client's mcpServers config. The client completes OAuth sign-in on first connect.
{
"mcpServers": {
"shodai-agreements": {
"type": "http",
"url": "https://shodai.network/mcp"
}
}
}README
@shodai-network/agreements-mcp-server
Model Context Protocol server for the Agreements API. Configure Shodai as a remote Streamable HTTP MCP server and the full agreement lifecycle — author, validate, preflight, deploy, submit inputs — becomes callable as MCP tools.
The server is a pure consumer of the public /v0 API via @shodai-network/agreements-api-client. It holds no business logic and stores no credentials: every tool call forwards the caller's API key or OAuth access token to the Agreements API gateway, which enforces auth, entitlements, and metering.
Hosted endpoint
Stateless Streamable HTTP: POST only, JSON responses, no server-side sessions. Use this hosted setup contract:
The canonical hosted endpoint advertises Shodai's testnet authorization server. An OAuth-capable MCP client follows RFC 9728 protected-resource discovery, opens browser authorization, and reconnects with the resulting access token. Use environment: "testnet" for that OAuth connection.
When OAUTH_AUTHORIZATION_SERVERS is set, the server:
- Serves RFC 9728 protected-resource metadata at
/.well-known/oauth-protected-resource(and.../mcp) - Challenges unauthenticated
POST /mcpwithWWW-Authenticate(resource_metadata=...) - Accepts OAuth access tokens (
Authorization: Bearer <jwt>) in addition to API keys
API keys remain supported as a fallback and as the production credential path. Send Authorization: Bearer cns_pk_... and match the key to the tool environment: testnet keys use testnet, and production keys use production.
First-flight setup, tool access, and typed-data preparation: Quickstart with MCP.
Run locally (stdio)
Stdio environment variables:
Tools
Most tools call the public /v0 API through the TypeScript client and carry MCP behavior annotations (readOnlyHint, destructiveHint). A few tools perform more than one operation to keep signing and deployment safe.
On the hosted endpoint, every API-calling tool below requires environment: "testnet" | "production". Local stdio mode uses the fixed environment from AGREEMENTS_API_ENVIRONMENT instead.
Resources are discoverable with resources/list:
Prompt: author_agreement (business description → agreement JSON).
Signing custody modes
Deploys and input submissions require EIP-712 permits. Three supported modes:
- Pre-signed permit — the agent or host app holds a wallet, signs externally, and passes
signer/deadline/signaturetodeploy_agreementorsubmit_input. - Prepare typed data, sign externally — call
prepare_deployment_typed_data/prepare_input_typed_datato get the exact EIP-712 payload, sign it with any EIP-712-capable signer, then call the write tool. For deployments, pass the returnednormalizedInitValues,normalizedParticipants, andnormalizedObserversback todeploy_agreementwith the signature. - Local environment signer (stdio only) — set
AGREEMENTS_SIGNER_PRIVATE_KEYand write tools sign locally. Dev/testnet pattern; the hosted endpoint never signs with server-side keys.
Minimal hosted flow: read simple-example-agreement, call validate_agreement, preflight_deployment, prepare_deployment_typed_data with environment/agreement/chainId/signerAddress and intended deployment context, sign externally, then call deploy_agreement with the same environment, displayName, matching docUri, normalized deployment fields, and permit fields. For inputs, call prepare_input_typed_data with environment/agreementId/inputId/values/signerAddress, sign externally, call submit_input with the same environment, then reread state and input history.
Hosted MCP receives signed permit fields only, never private keys. Private-key environment signing is for local stdio development and testnet automation only.
Self-hosting
HTTP environment variables: PORT, HOST, MCP_PATH, PUBLIC_MCP_URL, AGREEMENTS_API_TESTNET_BASE_URL, AGREEMENTS_API_PRODUCTION_BASE_URL, and optional local AGREEMENTS_API_BASE_URL for single-origin testing. Set PUBLIC_MCP_URL when discovery metadata should advertise a canonical public endpoint that differs from the request host.
A Dockerfile is included for container deployments. GET /healthz serves as the health endpoint.
Development
Verify interactively with the MCP Inspector:
Pin @latest: older Inspector versions do not support --transport/--header for URL targets.
License
MIT — see LICENSE. Note this package is MIT-licensed individually; other packages in this repository are licensed under Apache-2.0.
Source: packages/agreements-mcp-server/README.md at commit 5315578
Tools
0Version history
1- v0.1.0LatestSep 16, 2026
Score
85% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 daysRequired25 pts
- Auth declaredRequired10 pts
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts