Installing a local MCP server means running someone else's program on your computer, with your permissions, and letting an AI model decide when to use it. On an engineering firm's computer, that program may be able to reach client models, licensed software and network drives.
The questions below are for the person deciding whether to allow that. They aren't legal or security advice, and your firm's IT and security policies come first.
Why this matters
The MCP project's own security guidance says local servers "may have direct access to the user's system". It lists risks including arbitrary code execution, data exfiltration and irrecoverable data loss. Its setup guide puts it more simply: a server "runs with your user account permissions, so it can perform any file operations you can perform manually".
Engineering work adds its own concerns. Models can contain confidential client information, and an unwanted change to a model may not be obvious. Tresca lists 259 servers that can modify models and 33 that are read-only.
Who publishes it?
- Is it from the software vendor, or the community? On Tresca, "Official" links to the evidence. See the tracker. Official doesn't mean finished: many are labelled beta or pre-1.0.
- Who is the author, and can you find out more about them? A community project from one person isn't necessarily worse, but you carry more of the risk of it being abandoned.
- Is the source code available to read? Some free servers are closed source, and Tresca records the licence on each listing.
- Is it maintained? Listings show the last repository update, and archived or removed projects are marked. Note that star counts measure interest, not safety.
- Is the name what it seems? Check you're installing the package the project's documentation names. Listing pages link to where install steps came from.
What can it do?
- Can it change models, or only read them? Each listing shows "Can modify models" or "Read-only". Where a server offers a choice, as Autodesk's Revit server does with its Read, Write and Experimental configurations, start with the most limited.
- Can it run arbitrary code? Many servers include a tool that executes any script or command, in addition to their named tools. MathWorks says to review every tool call before it runs for its MATLAB server, since code execution is unrestricted. Bentley's OpenSTAAD server takes a different approach and sandboxes scripts, blocking imports and file access.
- Can actions be undone? Often they can't. Work on a copy and keep backups.
- What does the AI application ask before acting? Cursor and Claude Desktop ask for approval by default in their documentation. Find out what yours does, and who is allowed to turn that off.
What can it reach?
- Which files and folders? Some servers can be limited to specific folders, and some have no limit unless you set one. The U-C4N AutoCAD server, for example, documents an allowed-paths setting that is unscoped by default.
- Does it listen on the network? Local servers using the stdio transport talk only to the application that started them. Servers using HTTP can be reached by other programs unless protected, so check how they authenticate. The OpenSTAAD server's HTTP mode, for instance, requires a bearer token. The MCP guidance recommends stdio for local use, or restricting access if using HTTP.
- Can it reach your licence server or shared drives? It will have whatever access your user account has.
- Does it fetch anything from the internet? Claude Code's documentation warns: "Servers that fetch external content can expose you to prompt injection risk." That means text in a downloaded page could steer the AI's actions.
How is it installed and updated?
- What exactly does the install command run? The MCP guidance warns about malicious start-up commands placed in configurations. VS Code's documentation advises reviewing "the publisher, command or endpoint, and requested access". Tresca flags install steps that pipe a download straight into a shell.
- Does it fetch the latest version each time it starts? Commands such as
npx -yoruvxcan do this, so the code you run tomorrow may differ from what you reviewed today. Ask whether you can pin a version. - Does it need administrator rights? If so, find out why.
- Who updates it, and how will you know when an update matters?
Where does your data go?
- What does the AI provider receive? Anything a tool returns usually goes to the AI model as part of the conversation. If a tool reads a client model, assume that content leaves your computer unless your AI provider's terms and your setup say otherwise.
- Do those terms suit your contracts? Check client confidentiality clauses and any export-control restrictions on the data or software.
- Does the server send anything itself? The MATLAB server, for example, collects anonymised usage data by default and documents how to turn it off.
- Is it a remote service? Then your data also passes through that operator.
Skills need checking too
An agent skill is mostly text, but it can include scripts, and its instructions direct what the AI does. Read the SKILL.md and any bundled scripts before installing one.
Licences and responsibility
- Does your software licence allow automated or AI-driven use? Vendors' terms differ. Some restrict automation, remote access or use with third-party tools. Check your agreement or ask your vendor.
- What licence covers the integration? A listing showing "unknown" means the project doesn't state one, which limits what you may do with it. MathWorks' server, for instance, has a licence that permits use only with MathWorks products.
- Who approves it internally, and who is responsible for the output?
That last question has a firm answer on this site: AI-generated models, drawings and results must be checked by a qualified engineer before use. Nothing about the tool changes who is responsible for the engineering.
Using Tresca as a checklist
Each listing brings most of these facts together: origin, how it connects, access, operating systems, licence, install source and last activity. "Not stated in its documentation" means the project doesn't say, which is itself worth noting. See how we check listings for what we do and don't verify. We read each project's documentation; we don't audit code or test security.