Skip to content

Connect your own agent (MCP)

N3XD speaks the Model Context Protocol, so you can point a coding agent (Claude Code, Codex, Claude Desktop) at a project and have it model for you. The agent gets the same commands a person clicking in the UI gets, its edits land in the same feature history under your account, and they show up live in any browser tab you have open.

You bring the model. N3XD holds the CAD state, runs the geometry kernel and answers questions about the result. Nothing about your conversation reaches us, and a local model works as well as a hosted one.

Connect to the hosted app

The endpoint is https://app.n3xd.io/mcp. For Claude Code:

claude mcp add --transport http n3xd https://app.n3xd.io/mcp

The first call opens your browser to sign in and approve the connection. The agent then holds a token that acts as your account and can reach any project you can. Revoke it by signing that session out under Settings.

Self-hosting works the same with your own domain. The endpoint is part of the app container, so there is nothing extra to deploy; an administrator enables it under AI Tool → MCP access, which is also where the per-user command budget lives.

Which projects it can reach

The agent sees exactly what you see and always needs a project id. Give it the id from the URL (app.n3xd.io/p/<project-id>), or have it list your projects first.

Run it locally instead

For a standalone app with no accounts, the server also runs over stdio against a local backend:

cd backend
make dev-backend                                    # the app, on :8000
N3XD_MCP_ENABLED=1 uv run python -m n3xd.mcp        # the shim, another shell

N3XD_MCP_APP_URL points it at the app (default http://127.0.0.1:8000). For Claude Desktop, add an entry with an absolute path to app/backend so uv resolves the right environment:

{
  "mcpServers": {
    "n3xd": {
      "command": "uv",
      "args": ["run", "--directory", "/abs/path/to/app/backend", "python", "-m", "n3xd.mcp"],
      "env": { "N3XD_MCP_ENABLED": "1", "N3XD_MCP_APP_URL": "http://127.0.0.1:8000" }
    }
  }
}

This transport sends no credentials, so it only works against a standalone app (auth.mode="none"). Point it at a deployment with accounts and the calls are rejected; use the hosted endpoint for that.

A typical session

Have the agent call get_command_catalog first. It is versioned with the app, so the agent works from the surface your deployment actually has rather than from memory. From there the pattern is read, act, look:

  1. Read with get_model_tree for the structure, get_topology and find_entities to address geometry, get_sketch for a sketch's elements.
  2. Act with execute_command. It is the only write path and runs under the same per-project lock and revision check as the UI, so an edit you make in the browser at the same moment cannot be clobbered.
  3. Look with get_screenshot. The default four-view sheet (front, top, right, isometric) catches mistakes a single view hides. measure and get_diagnostics answer the numeric questions.

The tool reference lists everything and the command catalog documents the payloads.

Long-running tools

run_stress_study, run_flow_study and slice_part block until the job finishes, which can be minutes for a flow solve. Raise your client's timeout (MCP_TOOL_TIMEOUT in Claude Code) rather than re-running the job.

What the agent can and cannot do

It can do everything a modeling session involves, plus assemblies, parameters, configurations, simulation and slicing. It cannot delete a project, change sharing, or touch anything outside the projects your account can reach: the catalog does not contain those commands, and the server refuses any type that is not in it.

Every command it runs is recorded in the project's history with an mcp: actor, so you can see which changes came from an agent and undo them like any other edit.