Precogly MCP
OfficialClick on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Precogly MCP start a threat model for our new payment processing service"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Precogly MCP
MCP server for Precogly threat modeling.
Status
Early. Four tools, all read-only:
list_threat_models— threat models in the caller's organizations, most recently updated first, withtotalbeside them. Mounted, that is everything the caller can read; over stdio it is one page of twenty, andtotalis how you tell the difference.search_threat_library,search_countermeasure_library,search_component_library— the shared catalogs installed packs populate, withmatchedandcatalogSizebeside the rows.
Both transports work end to end. A tool reads Precogly through a protocol the mounting application supplies rather than by forwarding the caller's token, which cannot work mounted: a token issued for the MCP endpoint is audience-bound and invalid at Precogly's REST API by construction (0008).
Related MCP server: GauntletCI-MCP
Two transports
Which one you run decides where the credential comes from, and nothing else. The tools, their schemas and their results are identical.
mounted in Precogly | stdio | |
credential | a user authorizes in a browser; the token is the caller's |
|
lifetime | 10 hours, refreshed by the client without a prompt | 60 minutes, re-exported by hand |
acts as | the user who authorized it | whoever the token belongs to |
verified by | the mounting application, against its own tables | not verified; forwarded as-is |
The mounted transport is the product (0008); stdio is what predates it and what the MCP specification prescribes for a server that speaks over a pipe.
Mounted
Precogly serves the endpoint from its own WSGI process at /mcp, and supplies a token
verifier — this package never imports Django. config/mcp_mount.py in the Precogly
repository is the whole of the wiring. A client then needs no configuration beyond the
URL:
{
"mcp": {
"precogly": {
"type": "remote",
"url": "http://localhost:8000/mcp",
"enabled": true
}
}
}For opencode, that is an opencode.json — either in the project
root or in ~/.config/opencode/, which makes the server reachable from any directory —
followed by:
opencode mcp auth precogly # discovery, registration, browser consent
opencode mcp list # ✓ connectedThe client discovers where to authorize from the 401 this endpoint returns, registers itself, and sends the user to Precogly's own login and consent screens (0004, 0009). Nothing is pasted anywhere.
Stdio
Two environment variables, both read by the server process:
| Bearer token for the Precogly API. Required. |
| Base URL of the deployment. Defaults to |
Against a locally seeded instance, a token comes from the login endpoint:
export PRECOGLY_URL=http://localhost:8000
export PRECOGLY_TOKEN=$(curl -s -X POST "$PRECOGLY_URL/api/auth/login/" \
-H 'Content-Type: application/json' \
-d '{"email":"admin@precogly.dev","password":"admin123"}' \
| python3 -c "import sys,json;print(json.load(sys.stdin)['access'])")Either entry point runs it:
uv run precogly-mcp # console script
uv run python -m precogly_mcp.server # equivalentUnder the MCP Inspector, for poking at schemas by hand. --with-editable . is required —
mcp dev runs the file in an ephemeral environment containing only mcp, so without it
nothing in this package imports:
uv run mcp dev src/precogly_mcp/server.py --with-editable .Development
This project uses uv for dependencies and tooling.
uv sync # create .venv and install deps + dev tools
uv run pytest # run tests
uv run ruff check . # lint
uv run ruff format . # format
uv run mypy src # type-check (strict)
uv run pip-audit # scan dependencies for CVEsInstall the git hooks once:
uv run pre-commit installTests need no running Precogly. mcp.client.Client drives the server over in-memory
streams, so tools/list and tools/call are exercised as a client sees them, and
httpx2.MockTransport stands in for the API.
That transport is also their blind spot: every test passed against a version of
tools/call that failed on the first real request, because the fake never enforced the
audience binding a live token carries. A change to how tools reach data, or to what
Precogly's serializers return, wants a run against a seeded stack before it is believed.
Design
0001 — service token model (partially superseded by 0003)
0002 — tool implementation order
0003 — Precogly is the authorization server (resource server superseded by 0008)
0004 — where the user authorizes
0005 — code execution over tools
0006 — catalog search filters here
0007 — re-authenticating at consent
0008 — the MCP server runs inside Precogly
0009 — the authorization pages are built, not copied
0010 — the MCP app owns its resource metadata
Available Tools
1 toollist_threat_modelsList threat modelsARead-onlyIdempotent
List threat models in the caller's organizations, most recently updated first.
Each entry carries what a choice between models turns on: name, description,
criticality, owner, owning team, when it last changed, and the compliance frameworks
it touches. It does not carry a model's contents.
`frameworks` is incidence, not coverage. A framework is listed when at least one
countermeasure maps to at least one of its requirements, so a model addressing a
single control appears identically to one addressing every control. It answers
"which models touch SOC 2 at all", not "which models are SOC 2 compliant".
Returns at most twenty, and cannot reach past the first page. Treat a full page as
"at least twenty" rather than as the whole set.
Inputs: organization_id. Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The tool's purpose is clearly defined as listing threat models.
The single tool name 'list_threat_models' follows a clear verb_noun pattern. While there is no other tool to compare against, the name is unambiguous and well-structured.
A server with only one tool is too thin for a domain like threat models, which typically requires additional operations such as fetching details, creating, updating, or deleting. The single tool feels like a minimal stub rather than a complete server.
The tool surface is severely incomplete for threat model management. It only supports listing models and lacks any way to retrieve a specific model, create a new one, update existing ones, or delete them, leaving agents with a dead-end in the workflow.
Maintenance
Related MCP Connectors
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server that integrates with the MISP (Malware Information Sharing Platform) to provide threat intelligence capabilities to Large Language Models.13-
- AlicenseBqualityDmaintenanceMCP server that integrates GauntletCI to analyze behavioral change risk in commits, providing findings as text, JSON, or SARIF reports for AI assistants.31Elastic 2.0
- AlicenseBqualityCmaintenanceA comprehensive MCP server for structured threat modeling using STRIDE methodology, with automatic code validation and report generation.100125Apache 2.0
- AlicenseNot gradedqualityDmaintenanceServes any STRIDE threat model to MCP-capable LLMs, enabling natural language querying of threat registers and export to the Microsoft Threat Modeling Tool.MIT