MCP boundary review · software-only · USD 500
Know what it can do
before an agent does it.
We inspect one MCP server at one base revision, map what each tool and resource can read or change, run ten agreed protocol checks in a disposable environment, and return an evidence-backed go/no-go report.
The fit check and review happen in writing. No call required.
Start with metadata or a public repository. No credentials, production data, payment, or server access until the scope and handling rules are accepted in writing.
One base revision · up to eight tools/resources · ten checks · limited successor recheck.
A small, inspectable review
Map. Exercise.
Decide.
Free public-source preflight
Start with a public repository URL.
For a public GitHub repository, the open-source preflight pins the default-branch revision, reads a bounded set of public text files through the GitHub API, and maps likely tools, resources, transports, environment-variable names, host bindings, and side-effect clues. It never clones the repository or executes its code.
The static report is a starting inventory, not the paid review or a security verdict. A clean public repository URL is also enough for the first fit-check reply.
Default ten-check set
The cases are visible before you buy.
These are the defaults. A fit review may substitute a case when the server has a different risk, but the total stays at ten. Read the practical ten-check guide →
Handshake and discovery
Negotiate the supported protocol version, then compare the live tool and resource inventory with the advertised surface.
Valid calls and result handoff
Exercise an agreed valid tool call and resource read, checking actual data access, output bounds, pagination or resource handoff, and whether the intended client can resolve every returned locator.
Invalid requests
Send an unknown name and malformed or missing input, then record rejection behavior, messages, and any unintended side effect.
Authority and disclosure
Trace reads, writes, external calls, and approval gates; inspect agreed outputs and logs for credentials, paths, or private context that should not escape.
Failure and deployment boundary
Exercise one safe failure or timeout case, then decide whether the intended client and transport have the authentication and isolation the server assumes.
Limited follow-up recheck
Within fourteen calendar days, provide one successor revision of the same server, transport, and reviewed surface. We re-run up to three checks that failed in the original report.
What comes back
A decision tied to evidence.
The result keeps the advertised protocol surface, actual authority, executed cases, and unresolved risks together.
Authority map
For each reviewed tool and resource: inputs, outputs, reads, writes, external calls, credential use, human approval points, and worst credible failure.
Protocol packet
Frozen revision and environment, tool/resource inventory, ten agreed checks including calls, rejection cases, and inspected controls, sanitized logs, observed outputs, and reproducible commands.
Go/no-go report
A failure ledger ranked by impact, the safe operating boundary for this revision, and the smallest next fix or separate implementation scope.
Code and protocol, not theatre
Read-only labels are checked against behavior.
Tool annotations are useful signals, but they are not enforcement. The review looks for the controls underneath them: storage modes, allowlists, input bounds, external calls, authentication assumptions, and failure behavior.
You provide
A public or rights-cleared repository revision, setup instructions, the intended client and transport, and a description of sensitive data or actions without sharing the data itself.
We agree first
The exact surface, ten checks, disposable test environment, permitted network calls, secrets handling, success signals, retention, and delivery format.
You keep control
No production write, destructive operation, credential, or private dataset is used unless separately authorized and scoped. Public proof never includes customer material.
Executed public sample
A multilingual knowledge server, checked end to end.
The sample reviews the public Local Knowledge Terminal MCP bridge using the official Python MCP SDK and a project-owned PocketPolyglot fixture.
Frozen at LKT e750e5a
Two tools. One resource. Fourteen passing tests.
The SDK listed and called both tools, read the status resource, and traced a Japanese query to Chinese evidence and its source hash. The report records a narrow GO for local read-only use and a NO-GO for direct remote exposure without authentication.
This is project-owned evidence, not a customer result, penetration test, or production certification.
Sample decision
GO locally.
NO-GO remotely.
Working terms
The server and checks are fixed before payment.
Timing
Delivery is within seven business days after secured payment, repository access, working setup instructions, and every agreed test dependency are available. Only one MCP review is active at a time.
Follow-up recheck
Within fourteen calendar days, one successor revision of the same server, transport, and reviewed surface may re-run up to three checks that failed in the original report. New tools, resources, cases, or implementation work are a new scope.
Cancellation and refund
Cancel before private access or execution begins for a full refund. Once work starts, USD 100 covers environment setup, USD 150 the authority map, USD 150 the protocol packet, and USD 100 the final report; only undelivered items are refunded.
Exclusions
No fix implementation, penetration test, security certification, OAuth build, production deployment, destructive live testing, SLA, performance guarantee, or ongoing monitoring is included.
MCP Server Pre-Deployment Review · USD 500
Start with the smallest server boundary that matters.
Describe the repository, protocol surface, and intended client first. If it fits, both sides accept the exact checks, handling rules, and delivery terms before payment. Direct-site clients receive a Stripe request; marketplace clients keep the contract and payment on that marketplace.