The AllSign MCP server exposes two surfaces: tools and resources.

Tools

Stateful operations. 37 tools covering agreements, templates, contacts, participants, comments, and the signing ceremony. Call a tool to change state.

Resources

Read-only context. 12 resources covering actor identity, agreements, participants, comments, decisions, revisions, contacts, and templates. Read a resource to inspect current state.

Transport is streamable-http. The server listens at /mcp.

POST / HTTP/1.1
Host: mcp.allsign.app
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json

All requests and responses use JSON-RPC 2.0. Health check endpoint: GET /mcp/health.

Pass a bearer token in the Authorization header. Three token types are available:

Personal access tokens

Issued to a human account. Operations run as that user. For human-in-the-loop integrations only.

Application tokens

Issued to an application credential. Use for service-to-service integrations where agent identity is not required.

Agent application tokens

Issued to an agent actor. Operations run as the named agent. Use this type for autonomous AI agent integrations. The agent appears in audit trails by name.

For agent-driven integrations, use an agent application token. Create one in Settings > Applications.

Agents use the same five participant capacities as human participants. Capacity is set when the agent is invited to an agreement. The audit trail records every agent action identically to human actions. Signature requirements apply to agents in the Signer capacity.

Author

Creates and manages the agreement. Can revise terms, control structure, invite participants, and manage attachments.

Commentor

Provides feedback through comments. Cannot alter content, record decisions, or sign.

Editor

Modifies terms and invites participants. Cannot delete the agreement. Edits after signing revoke existing signatures.

Signer

Reviews terms, records decisions (accepted/rejected), and executes digital signatures. Can withdraw before execution.

Viewer

Read-only access throughout the lifecycle, including after execution or rejection.

The connection configuration below derives from the spec server section.

{
  "mcpServers": {
    "allsign": {
      "transport": "streamable-http",
      "url": "https://mcp.allsign.app/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}

transport: streamable-http and url are from the spec server section.

1. 1Discover available tools and resources: call tools/list and resources/list.
2. 2Read a resource to get current context: call resources/read with the resource URI.
3. 3Call a tool to change state.
4. 4Read the resource again to verify the change.

The signing ceremony is protocol-driven. Read the protocol resource to determine which tool to call next.

1. 1Read mcp://allsign/agreements/{agreement_ref}/protocol.
2. 2Inspect the state field and the action field. The action contains the next tool to call and its required input schema.
3. 3Call the tool named in action.name with the parameters from action.schema.
4. 4Read the protocol resource again.
5. 5Repeat until action is null and state is idle.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/read",
  "params": {
    "uri": "mcp://allsign/agreements/AGREEMENT_REF/protocol"
  }
}

• The MCP server uses JSON-RPC 2.0, not REST. All requests are POST /mcp.
• Resources are identified by mcp:// URIs, not HTTP paths.
• The signing ceremony is protocol-driven: the server tells the agent which tool to call next. The REST API requires the client to determine the next step.
• Tool call results include both structured content and text content.
• The MCP surface and the REST API share the same domain operations. Behavior is aligned across both surfaces.