FAQ
The questions we get most often about Devici MCP.
What is Devici MCP, exactly?
A hosted endpoint that exposes Devici as a set of tools to any AI client that speaks the Model Context Protocol (MCP). You create an API token in your Devici workspace, paste its clientId and secret into your AI client config, and your agent can build, update, and maintain threat models directly in Devici without leaving your editor.
Do I need to install anything?
No. Devici MCP is hosted by Devici. You configure your AI client with the endpoint URL and your client credentials. Nothing runs on your machine.
How is this different from the Devici Standard API?
Both let you read and write Devici programmatically, but they serve different purposes:
| Devici MCP | Devici Standard API | |
|---|---|---|
| Audience | AI clients (Cursor, GitHub Copilot, Claude Code) and the agents inside them | Any HTTP client. Backend integrations, scripts, automation. |
| Surface | A curated set of tools (17 today) wrapping common workflows | Full CRUD on every resource |
| Auth | API token (clientId + secret), issued in your Devici workspace. The token's scopes are enforced per call. |
Same credential model |
| Best for | Agentic work, IDE-driven threat modeling, conversational tasks | Custom integrations, automation, bulk data operations |
Both surfaces hit the same Devici platform and the same audit log. They aren't competing. They're for different jobs.
Which AI clients work with Devici MCP today?
The validated AI clients are:
- Cursor
- GitHub Copilot (in VS Code)
- Claude Code
Any other client that speaks remote MCP over Streamable HTTP can also connect, but the three above are the ones we test against. Devici MCP supports the Streamable HTTP transport only, so clients that speak only stdio MCP today aren't supported.
See Client setup for setup steps per client.
Can I use Devici MCP from CI or pipelines?
Yes. Issue the credentials in your Devici workspace under an identity appropriate for non-interactive use (a dedicated service identity, not a person's account), then configure your pipeline to call https://mcp.devici.com/mcp with the two X-Devici-* headers the same way an AI client does. The credential's permissions are whatever that identity has in Devici.
Store the secret in your CI provider's secret manager, never in source control.
See Authentication for the issuance flow.
Where are my credentials stored?
| Devici (server side) | Inherits the same credential storage posture as the rest of the Devici platform |
| Your AI client | In your OS keychain or the client's secret-storage backend, depending on the client. Don't paste the secret into a plain config file in source control. |
| Your CI provider | In whatever secret-manager surface that provider exposes |
| Source control | Never. Treat the secret like a password. |
Will my data leave my Devici workspace?
No. Devici MCP is part of the same hosting profile as the Devici platform. Tool calls hit your workspace, return data from your workspace, and never cross workspace boundaries.
Devici MCP also does not receive your AI client's full chat context. It only receives the structured tool calls the agent makes. Source code, prompts, and surrounding conversation stay in your AI client and, when the client decides to send them, in your chosen LLM provider's pipeline.
Does Devici send my data to a third-party LLM?
No. Devici does not run inference, does not host LLMs, and does not forward customer data to third-party model providers as part of the MCP product. The LLM is operated by your AI client, and the LLM only sees data that client passes to it. Your relationship with your LLM provider is governed by your own agreement with that provider, not by Devici.
Can the agent see my code?
The agent reads code on your machine. It's running inside your AI client. What it sends to Devici MCP is whatever it passes as tool arguments. In a typical "build a threat model from this repo" flow, that's structured architecture descriptions (component names, dataflows, threats) and OTM JSON payloads, not raw source files.
Whether the agent includes code snippets in a tool argument is a behavior of the AI client, not of Devici MCP. If your organization has a policy against AI clients reading source, that policy is enforced by your client and IDE configuration, not by Devici.
Can I export my threat models?
Yes. Use the threat_model_export tool (or the equivalent UI in the Devici web app). Two formats are supported:
otm(default) — the Open Threat Model JSON, identical to the UI's OTM export and round-trip-safe withthreat_model_import_otmsummary— counts and component/threat names only, for quick overviews
What's the difference between threat_model_create and threat_model_import_otm?
threat_model_create |
threat_model_import_otm |
|
|---|---|---|
| Creates the model | Yes | Yes |
| Creates a visual canvas | No. Empty canvas. | Yes. Fully rendered. |
| Best for | API-style creation when you don't need the diagram | Anything visual, which is most cases |
| Input shape | Flat lists of components, threats, mitigations | OTM JSON |
For 95% of "build me a threat model" requests, use threat_model_import_otm. The agent will author the OTM for you. You don't need to write it by hand.
Why are some threats and mitigations called "codex"?
The codex is Devici's curated library of attributes, threats, and mitigations. Built-in threats are tagged to methodologies like STRIDE, MAESTRO, and LINDDUN; attributes and mitigations themselves aren't tied to a framework — they describe component properties and controls. Custom codex content is yours: your organization's own threat and mitigation library.
How do I limit threats to a specific methodology?
"Methodology" and "framework" mean the same thing in Devici — STRIDE, MAESTRO, LINDDUN, etc. Use whichever term feels natural; the agent understands both.
Methodology scoping is a setting on the threat model itself — and it accepts one or many methodologies. When you ask the agent to "use STRIDE only", "frame this with MAESTRO", or "apply STRIDE and LINDDUN together", the agent updates that setting on your model — which then restricts which framework-tagged threats the codex brings in when attributes are assigned.
Key behaviors:
- The setting persists on the model. The next attribute pass on that model uses the same methodology filter; you don't have to repeat it.
- Multiple methodologies are supported. Ask for STRIDE + MAESTRO together and threats tagged with either will surface.
- Clearing the methodology filter (asking "remove the methodology restriction") re-enables threats from all methodologies. If you also have the custom codex turned on, it stays on.
- Removing all framing (asking "remove all framing" or "reset the model's scoping") clears both the methodology filter and the custom-codex inclusion in one step — every methodology's threats surface from then on, and the custom codex is no longer pulled in.
- The filter applies to future attribute assignments. Threats already attached when you change the methodology are not retroactively removed. If you change framework after a codex pass, ask the agent to re-run the affected components or to remove off-methodology threats explicitly.
- Your org's custom codex can be included alongside built-in methodologies. Just ask — "also use our custom codex" or "apply STRIDE plus our org codex". The agent updates the model so both sources contribute threats.
Assigning codex attributes to a component automatically syncs the threats they cause and each threat's default mitigations. So in many flows, you only need to assign attributes. The rest follows.
Tools that work with the codex are prefixed codex_*. See the Tool reference → Codex content section.