The SDC MCP Servers

An MCP server is a tool surface that an AI assistant calls over stdio: the assistant sends one JSON-RPC 2.0 request per line on standard input and reads one response per line on standard output. Nine open-source packages of the Semantic Data Charter ship such a server, so an assistant can build a model in SDCStudio, read a published model, validate a Governed Data Record against it, evaluate governance over it, settle it, and describe it in another standard's terms, all without importing a Python library. None of them depends on an external MCP SDK; each implements the protocol directly.

SDCStudio itself hosts no MCP server. The reader and the projections read its public catalog and schema routes, described in public-catalog-api.md; sdcmodeler calls its authenticated API with your API key.

The nine servers

Every server is registered in the MCP registry under the name in the third column, as a PyPI package with stdio transport: the eight libraries of the Semantic Data Charter under io.github.SemanticDataCharter/, and sdcmodeler, the client for SDCStudio, under io.github.Axius-SDC/. Each repository carries a server.json with that registration.

The reader and the four projections

sdcreader reads a published model's package: the catalog record, the JSON-LD description of the model and its components, the schema bytes from /dmlib/, and the versions file. The four projection packages (sdc_cdif, sdc_dcat3_us, sdc_dcat3_ap, sdc_healthdcat_ap) depend on it and describe the same package in another standard's terms. The protocol scaffold they share, sdcreader.mcp, lives in the reader once: protocol version negotiation on initialize, tool failures returned as isError results rather than JSON-RPC errors, and a per-process package cache, since a published package is immutable.

Every reader-based tool takes either a ct_id, the model's identifier in the public catalog, which is fetched from the host the server was started with, or a directory, a package already on disk. The projection tools that describe several models take ct_ids or directories as arrays. A contact_name, contact_email and date can be given; otherwise the package's declared defaults apply.

The validator, the governance engine and the receipt client

sdcvalidator and sdcgovernance take file paths: schema_path for the model's XSD and instance_path for the Governed Data Record. The schema can be the xsd artifact of a public model from the catalog, or one you generated yourself (see generating-outputs.md).

sdcreceipt takes documents as JSON objects: the Receipt, the issuer's key document, optionally a party key document and a governance Receipt. Its tools/list advertises only the tools the server can actually run with what it was started with, so a tool whose every call would fail is never offered. Started with no arguments it is verify-only. The settlement flow those tools belong to is described in verifiable-settlement.md.

The modeler: sdcmodeler

sdcmodeler is the one server that writes to SDCStudio. It searches the catalog, estimates a model, assembles and publishes it, and fetches its package (download_package, since 4.3.0) or an application, calling SDCStudio's API with the key it was started with. No tool takes a key, an address or a payment method. Without SDCSTUDIO_API_KEY the catalog tools work and estimate_model prices the tree locally by the same rule SDCStudio uses; building, downloading a package, generating an application and wallet need the key.

Three rules hold in the server itself, before SDCStudio is asked:

• No spend without an estimate shown. build_model takes the estimate_id that estimate_model returned for the same title and tree in this server process, and refuses a missing or different one. SDCStudio checks it again and answers 409 stale_estimate if the tree changed.
• Stop at the key's limit. When the key has a spending limit and the estimate is more than the key may still spend, build_model refuses and says how much is left.
• Never pay. A 402 is reported with the numbers in credits and the tool stops; the person adds credits under Settings > Wallet. generate_app refuses until it is called with confirm_charge: true, after the person has agreed to the 1,500 credits the first download of a model costs (later downloads of it are free).

The same client is a command line: sdcmodeler search, models, model, artifact, estimate, build (with --estimate-id, --draft, --no-generate, --wait), job, package, app and wallet. Its README is at github.com/Axius-SDC/sdcmodeler.

Configuring a desktop assistant

Assistants that support MCP take a list of servers, each with the command that starts it. A generic entry for the reader, using the launch command from its README, looks like this:

{
  "mcpServers": {
    "sdcreader": {
      "command": "uvx",
      "args": ["sdcreader"]
    }
  }
}

The same shape starts any of the others: "args": ["sdccdif", "mcp"] for the CDIF projection; "args": ["sdcvalidator", "mcp"] for the validator; or "command": "sdcreceipt-mcp" with "args": ["--key", "vsl-party.pem", "--key-id", "https://vendor.example/.well-known/vsl-key.json"] for a receipt server that can sign. The modeler takes its key from the environment, so the key stays out of the conversation:

{
  "mcpServers": {
    "sdcmodeler": {
      "command": "uvx",
      "args": ["sdcmodeler", "mcp"],
      "env": {"SDCSTUDIO_API_KEY": "sdcs_..."}
    }
  }
}

Consult your assistant's documentation for where the file lives.

A key for an agent

An agent that writes to SDCStudio holds an API key. Create it with the scopes the agent needs and a spending limit (Settings, API Keys; see API Keys): Build without Spend for an agent that searches, proposes and estimates (an estimate is a POST, so it needs Build); Spend with a limit for one that mints and assembles. Spend without Build is refused on every call but an application download. The server refuses a call the key may not make before anything is built, and the agent reports the refusal to you. A key cannot create, rotate or widen keys, or change the account or its auto-reload; those take you signed in (see API Keys).

An agent builds a model, end to end

1. You create the key. In Settings > API Keys, with Build, Spend and a spending limit. Put it in the assistant's configuration as SDCSTUDIO_API_KEY (above).
2. The agent looks for what exists. search_components and list_models find published components and models to reuse; a reused component is free and keeps the model joinable with every other model that uses it.
3. The agent shows you the estimate. estimate_model returns what would be reused, what minted, the total in credits (500 for the model, 100 per new component and per new cluster below the root), whether the wallet can pay (can_pay) and whether the key may (within_limit).
4. You agree; the agent builds. build_model with that estimate_id. A 409, 402 or 403 stops it, and the agent tells you why.
5. Every component reused: the model comes back published, with its package. Something new: the result carries a job_ct_id; the agent polls job_status until completed, when the job has published the tree, built the package and carries dm_ct_id, catalog_url and package_url. A failed job carries the reason.
6. The package. The model is built in your default project, which is private, so the package is fetched with the key: download_package (or sdcmodeler package <ct_id> at the command line, or the job's package_url with the key in the header). get_model and the public catalog cover models in public projects only. generate_app builds and downloads an application only with confirm_charge.

For the same steps over HTTP, without sdcmodeler, see the assembly reference.

What the servers do not do

• No tool takes a URL. The catalog host of the reader and the projections is fixed at start with --host; the issuer endpoint of sdcreceipt is fixed at start with --endpoint; the SDCStudio that sdcmodeler writes to is fixed at start with --url or SDCSTUDIO_URL. A caller cannot point a server at another host.
• No account. The reader and the projections need no account anywhere; the validator and governance servers work on local files. Receipt verification needs no network and no account. Two servers need an account: sdcreceipt's settle, with an API token for the issuer given at start as --token or SDCRECEIPT_TOKEN, and sdcmodeler's build_model, download_package, generate_app and wallet, with the key given as SDCSTUDIO_API_KEY.
• No key generation and no submission in sdcreceipt. init is not exposed because a private key generated inside an assistant session has no clear custody story; it stays a human act at a terminal. sign_trigger returns a signed trigger for you to submit; submission is not exposed because it would take a destination from the caller. The signing key and the identity it signs as are bound at start, never passed per call, so neither travels through the conversation.
• The projections' standards validators run in CI, not in the wheel. Each projection's output is checked in that package's CI with the standard's own framing, JSON Schema or SHACL artifacts from a pinned snapshot kept in the repository's data/ directory, with the validator libraries as a development extra. The wheel carries the package's declared input files only; the server writes the document and does not run those validators.
• Defaults are never reported as facts. The reader returns Dublin Core as the modeler wrote it; a field that still holds SDCStudio's default comes back as null.

Relationship to SDCStudio

SDCStudio publishes models; it does not host an MCP server. sdcmodeler is the one server that builds there: it calls the estimate, assembly, job, generation and wallet routes with your key (see the assembly reference). find_models calls GET /api/v1/catalog/dms/ on the host the reader was started with, which defaults to https://sdcstudio.axius-sdc.com, and lists only models from public projects. describe_model, list_leaves, list_codes and the projection tools fetch the model's package through the catalog record, its artifact pointers and the /dmlib/ schema routes. sdcreceipt's settle posts to the issuer's settle endpoint with an API key from Settings > API Keys (see api-keys.md); its verify_receipt reads the issuer's published key document, which SDCStudio serves at a fixed well-known path. A self-hosted SDCStudio is reached the same way by starting the reader or a projection with --host.