Skip to main content
About

Built for one problem: safer MCP integrations.

MCP Detect is a focused security review practice for teams shipping MCP into real product paths. Each engagement follows the same documented method, combines human judgment with inspectable tooling, and ends with evidence engineers can act on.

Why this, narrowly

MCP moves a real trust boundary into a place few people are reviewing yet.

When a model can call tools that read files, hold credentials, or act on data, the interesting security questions stop being about the network and start being about which tool calls are actually authorized, and what a crafted argument or a poisoned tool description can reach.

That is a specific problem. MCP Detect examines agreed trust boundaries in context, instead of running a broad scanner that reports strings without deciding whether they matter.

How the work is done

Methodical

A fixed sequence, documented on the method page, so a review is repeatable and a client knows exactly what happened and in what order.

Transparent

The framework's rules and its reproducible measurements are open to inspection. You verify the work rather than take a claim on faith.

Accountable

Findings are labeled by confidence, limits are written down, and MCP Detect stands behind the final report.

Honest about limits

Coverage is narrow and stated up front. A review that overclaims is worse than no review because it hides the risk it missed.

Why the method is open

Transparency is part of the operating model.

The service is human-led; the framework is internal delivery tooling, not the product being sold. Keeping it inspectable lets technical buyers and security leaders verify the work without trusting a black box.

A buyer pays for scoped source, configuration, identity, authorization, architecture and evidence review, not for a secret corpus or an automated scorecard.

Licensing

Why a permissive license

The tooling is offered under a permissive (MIT-style) license rather than copyleft. The business is a services engagement evaluated by technical buyers who need to read and verify code freely, not a product whose source has to be guarded. Openness serves the review; it does not compete with it.

Review the evidence
Next step

Read the work, then decide whether the scope fits.

Reproduce the evidence, inspect the source, then bring your MCP environment to review.

See the evidence
Request a review

Start a conversation

Tell us what your MCP environment can reach and what prompted the review. We'll reply with a clear scope and next steps.

Email [email protected] See the review scope