Which JACS Path Should I Use?

Choose the smallest supported integration that matches your deployment.

Start Here

If you need...Start hereWhy
Signed tool outputs inside LangChain / LangGraph on PythonPython Framework AdaptersSmallest path: sign tool results without adding MCP
Signed tool outputs inside LangChain.js / LangGraph on NodeNode.js LangChain.jsSame idea for TypeScript
A ready-made local MCP server for Claude, Codex, or another MCP clientMCP Overview and jacs-mcpFastest full server path
To secure your existing MCP server/client codePython MCP or Node.js MCPUse wrappers or transport proxies around code you already have
Cross-organization agent discovery and signed artifact exchangeA2A InteroperabilityMCP is not enough for this boundary
Signed HTTP APIs without adopting MCPPython Framework Adapters, Express, KoaSign requests or responses at the web layer
Multi-party approval or quorum workflowsMulti-Agent AgreementsAgreements are the right primitive, not just one-off signatures
Direct signing from scripts, jobs, or servicesQuick Start, Python Basic Usage, Node Basic Usage, Go InstallationStart from sign/verify before adding framework layers

When You Probably Do Not Need JACS

  • Everything stays inside one service you control and your own logs are enough
  • You only need integrity, not signer identity or third-party verification
  • A plain checksum or database audit log already satisfies the requirement
  1. Prototype with quickstart and simple sign/verify calls.
  2. Attach provenance at the boundary that already exists in your system: LangChain tool, FastAPI response, MCP call, or A2A artifact.
  3. Add trust policy only when other agents or organizations enter the picture.
  4. Add agreements, DNS, or attestations only if your deployment actually needs them.

The mistake to avoid is starting with the broadest story. Start with the boundary you need to secure now.