Allows deploying the MCP server behind Amazon Bedrock AgentCore Gateway, enabling Bedrock agents to call its verification tools remotely.
Click 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., "@VerifierMCP Is (x+1)^2 equal to x^2+1? Verify it."
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.
An MCP server that gives any LLM the power to check its own work. Instead of trusting a model's arithmetic, regex, JSON or "the code prints X", the model can call a tool and verify it. Five verification tools over the Model Context Protocol: symbolic math, sandboxed code execution, JSON-Schema validation, dimensional analysis, and regex testing.
Built with the official MCP Python SDK (FastMCP). Works in Claude Desktop and any MCP client over stdio, or remotely over streamable HTTP (e.g. behind Amazon Bedrock AgentCore Gateway).
LLMs are confidently wrong about exactly the things that are mechanically checkable:
(x+1)² = x²+1, a regex that doesn't quite match, JSON that violates its schema, a unit
slip, "this function returns 5050". VerifierMCP turns each of those into a tool call, so an
agent can replace an assertion with a verified fact.
Related MCP server: leftbrain
Tool | Checks | Engine |
| Is an equation an identity? Does a claimed result hold? | SymPy |
| What does this Python snippet actually output? | sandboxed subprocess |
| Does this JSON conform to its JSON Schema? | jsonschema (Draft 2020-12) |
| Is this quantity/equation dimensionally correct? | Pint |
| Does this regex match/reject the right cases? |
|
Each tool body lives in src/verifier_mcp/tools/ as a pure
function, so it is unit-tested without the protocol and reused by the web playground.
pip install -r requirements.txt
# Run the MCP server over stdio (what Claude Desktop launches)
PYTHONPATH=src python -m verifier_mcp.server
# Or serve it over HTTP (MCP streamable transport on :8000/mcp)
PYTHONPATH=src python -m verifier_mcp.server --http
# See it in action — the visual playground
PYTHONPATH=src uvicorn verifier_mcp.playground:app --port 8080 # http://localhost:8080Add to claude_desktop_config.json:
{
"mcpServers": {
"verifier": {
"command": "python",
"args": ["-m", "verifier_mcp.server"],
"env": { "PYTHONPATH": "/absolute/path/to/verifier-mcp/src" }
}
}
}Restart Claude Desktop and ask it something like "Is (x+1)² equal to x²+1? Use the verifier."
— it will call verify_math and come back with the checked answer.
examples/self_checking_agent.py connects a Groq LLM to
this server over real MCP (via langchain-mcp-adapters), instructs it to verify before
asserting, and watches it catch its own mistake:
pip install -r requirements-demo.txt
export GROQ_API_KEY=gsk_... # real Groq agent
python examples/self_checking_agent.py
python examples/self_checking_agent.py --offline # no key: scripted LLM, REAL MCP verification[offline] Question: Is (x+1)^2 equal to x^2 + 1? If not, what is the correct expansion?
[Assistant] draft answer: "(x+1)^2 = x**2 + 1"
→ verify_math((x+1)**2, claimed_result=x**2 + 1) [real MCP call]
MCP result: verified=False — expression simplifies to (x + 1)**2, not x**2 + 1
→ verify_math((x+1)**2, claimed_result=x**2 + 2*x + 1) [real MCP call]
MCP result: verified=True
[Assistant] Corrected: (x+1)^2 = x^2 + 2x + 1 — verified, not x^2 + 1.The HTTP transport (--http, container in Dockerfile) exposes a standard MCP
endpoint at /mcp. Point AgentCore Gateway at it to turn these verifiers into tools any
Bedrock agent can call:
docker build -t verifier-mcp .
docker run -p 8000:8000 verifier-mcp # MCP over HTTP at http://localhost:8000/mcprun_code executes snippets in a fresh python -I -S subprocess with no inherited
environment, a temp working dir, and POSIX resource limits (CPU, memory, no forking,
no file writes) plus a wall-clock timeout. That is appropriate for a local dev tool. For
untrusted, multi-tenant use, run the whole server inside a container / gVisor / Firecracker —
the subprocess limits are defense-in-depth, not a complete jail.
PYTHONPATH=src pytest -q # 18 passed — tool logic + MCP protocol registration/dispatchModel Context Protocol (FastMCP) · SymPy · jsonschema · Pint · FastAPI · Docker · GitHub Actions · Amazon Bedrock AgentCore Gateway–ready
MIT © Arash Omranpour
Dimensional analysis (Pint). Evaluate a quantity expression like '5 meter / second * 2 second'; optionally check it matches expected_unit.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | ||
| expected_unit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully names the engine (Pint), which sets expectations about supported unit syntax, but it never says what happens on a unit mismatch (error vs. boolean) or confirms the operation is side-effect free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core action and the example front-loaded; every clause carries information and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and both parameters are covered. The remaining gap is behavioral: mismatch semantics and failure modes are undefined for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it largely does: it explains that 'expression' is a quantity expression (with a worked example) and that 'expected_unit' is an optional comparison target. Syntax edge cases (e.g., accepted unit aliases) remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: evaluate a quantity expression via dimensional analysis, with a concrete example ('5 meter / second * 2 second'). The purpose is unmistakable, though it never explicitly contrasts itself with the adjacent verify_math sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the example and by 'optionally check it matches expected_unit'. There is no statement of when to prefer this over verify_math or run_code, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Python snippet in a sandboxed subprocess and return its stdout/stderr. Use to check that code does what it claims.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| stdin | No | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the execution model ('sandboxed subprocess') and the return channel, but says nothing about isolation limits, network/filesystem access, what happens when timeout is exceeded, or error/exit-code behavior — material facts for arbitrary code execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the mechanism is front-loaded and the usage hint follows. No filler, no restatement of the name, appropriate size for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers the stdout/stderr return, so return values need not be re-explained. However a code-execution tool with no annotations, 0% parameter coverage, and unstated sandbox limits/consequences leaves real gaps around timeout, stdin, and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters, so the description must compensate and does not. 'Snippet' loosely maps to code, but stdin and timeout (default 5s) are never mentioned, leaving an agent with no idea what stdin feeds or that the timeout is configurable and how it behaves on expiry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run a Python snippet in a sandboxed subprocess') plus the return channel (stdout/stderr), so the action is unambiguous. It implicitly positions itself as the general-purpose verifier against the narrow siblings (verify_math, check_units), but never names them, so sibling differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use to check that code does what it claims' gives one positive usage context. It offers no when-not guidance and never contrasts itself with the specialized siblings (verify_math, test_regex, validate_schema), which is exactly where an agent would hesitate between this tool and a cheaper targeted one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a regex against labelled cases [{text, should_match}]; returns per-case pass/fail and capture groups.
| Name | Required | Description | Default |
|---|---|---|---|
| cases | Yes | ||
| flags | No | ||
| pattern | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it leaves key behaviors unstated: what happens with an invalid or uncompilable pattern (error vs. per-case failure), whether all cases run or it short-circuits, and how flags affect matching. Noting 'per-case pass/fail and capture groups' is largely a restatement of what the output schema already exposes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that leads with the action and input shape, then the return. No filler, nothing redundant, nothing misplaced.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, and the description supplements the schema with the case-object shape. It stops short of covering flags semantics and invalid-pattern behavior, which is the main remaining gap for a tool of this modest complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add real value by disclosing the item keys of the otherwise opaque 'cases' array ({text, should_match}), but it says nothing about the 'flags' parameter (default '') or expected pattern syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Test a regex against labelled cases' — and names the input shape and output, so the operation is unambiguous. It does not differentiate itself from the sibling verifier tools (verify_math, validate_schema, check_units), though the domain difference makes confusion unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the mention of 'labelled cases [{text, should_match}]' signals this is a labelled-test harness, so an agent can infer it is for checking a candidate pattern against known expectations. There is no explicit when-to-use/when-not guidance or comparison against alternatives such as run_code for ad-hoc regex execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a JSON instance against a JSON Schema (Draft 2020-12). Returns validity and a list of errors.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | ||
| instance | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the JSON Schema draft version and that it returns validity plus an error list, but says nothing about how malformed input is handled, whether it throws versus returning invalid, or performance limits. An output schema exists to fill in the return shape, so the added value here is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero waste; the core purpose is front-loaded and the return/version details follow. Nothing could be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter validator with an output schema covering return values, the description is largely sufficient, and the draft disclosure is valuable. It stops short of stating edge-case behavior for invalid or unparseable input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the two parameters are documented only by bare titles 'Schema' and 'Instance'. The description's phrasing does implicitly map both names to their roles (instance validated against schema), but adds no format, encoding, or structural guidance beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Validate a JSON instance against a JSON Schema') and pins the dialect with '(Draft 2020-12)'. It is clear and unambiguous, though it does not explicitly distinguish itself from siblings like test_regex or verify_math, relying on the obvious domain difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no exclusions or named alternatives. The use case is only implied by the verb 'Validate', leaving the agent to infer when schema validation is the right call versus check_units or test_regex.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify algebra/calculus symbolically (SymPy). Pass an equation with '=', or an expression plus claimed_result.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | ||
| claimed_result | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the engine (SymPy) and that verification is symbolic, but says nothing about failure behavior, error conditions, or limits (e.g., unsupported constructs, timeouts). That is adequate but thin for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose and immediately followed by the input contract. Every clause carries information, though the parenthetical '(SymPy)' is minor implementation detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. The input modes and required field are covered well enough to call the tool, with only minor ambiguity about when claimed_result becomes mandatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: 'expression' is explained as either a full equation containing '=' or a bare expression, and 'claimed_result' as the value to check it against. The only gap is that it doesn't explicitly state claimed_result is required in the bare-expression mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (algebra/calculus expressions) plus the method (symbolic, via SymPy), which cleanly separates it from check_units and test_regex. It never names a sibling or states what it is not, so an agent must infer the boundary against run_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives input-shape guidance ('equation with =' vs 'expression plus claimed_result'), which implies two usage modes but not when to prefer this tool over run_code or check_units. There is no explicit when-to-use or when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_unitsrun_codetest_regexvalidate_schemaverify_mathScored across 5 tools
Each tool targets a clearly distinct validation domain: symbolic math, code execution, JSON Schema, dimensional units, and regex testing. There is no overlap in purpose; an agent can easily select the right tool based on the task type.
All names follow a consistent snake_case verb_noun pattern: verify_math, run_code, validate_schema, check_units, test_regex. The verbs are distinct but appropriate to each action, and the naming is highly predictable.
Five tools is a well-scoped size for a verification toolkit, covering a focused set of common checking tasks without redundancy. Each tool earns its place and the set feels neither bloated nor thin.
The set covers core verification areas (math, code, schema, units, regex) with no dead ends within those domains. Minor gaps exist, such as XML/YAML schema validation or tolerance-based numeric comparison, but agents can work around them with run_code.
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Small tools for agent builders: AI-writing tells, tools/list token cost, CLAUDE.md lint, and more.
