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., "@thinking-mcp help me reason through why our API latency spiked, deep mode"
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 forces the host AI to reason through a structured protocol.
The protocol itself calls no LLM: no API key, no GPU, no inference cost. On top of it, an optional quality layer (below) can add a semantic audit, per-problem probes, and verification the server runs itself — off until you configure a provider, and never able to fail a submission.
A CAPABLE AI != AN AI THAT THINKS WELL
The problem is not IQ — it is discipline and structure.Claude 4 and GPT-5 are already smart enough. What they do when answering freely is skip steps:
Failure mode | Symptom |
Anchoring | Jumps on the first hypothesis |
Overconfidence |
|
Sunk cost | Never backtracks after being shown wrong |
Confirmation bias | Only searches for supporting evidence |
Symptom solving | Fixes the leaf, not the root |
Single hypothesis | Offers one possibility and stops |
No inversion | Never attacks its own idea |
thinking-mcp does not make the model smarter. It makes the model not skip steps.
Related MCP server: Ouroboros
Is: an MCP server that renders a scaffold, validates structure, and formats output. Isn't: an LLM proxy, a model aggregator, a caching layer, a silver bullet, or "an IQ boost".
┌────────────────────────────────────────────────────────────┐
│ HOST AI (Claude / GPT / Agnes in Cursor) — THE BRAIN │
│ • Reasoning · creativity · context understanding │
└───────────────────────┬────────────────────────────────────┘
│ MCP (stdio)
▼
┌────────────────────────────────────────────────────────────┐
│ thinking-mcp — THE COACH │
│ • Scaffold protocol · validate · format │
│ • 0 API calls · 0 API keys (default) │
│ • optional: audit · probes · verify (your key) │
└────────────────────────────────────────────────────────────┘QUICK | STANDARD | DEEP | |
When | Simple questions | Most questions | Hard problems |
Steps | 3 | 5 | 11 |
Scaffold tokens (measured, rendered) | ~170 | ~550 | ~1,140 |
For | Factual, lookup | Debugging, design, review | Architecture, strategy, root cause |
The mode is auto-selected from the question text; the caller can always override with
mode="deep". Every mode names its own breaking point: the scaffold tells the host AI
when to switch modes instead of grinding through the wrong depth.
DEEP walks through: Axioms ([TRUTH]/[ASSUMPTION] labels) → Decompose → Root Cause (5 Whys with a multi-cause guard: single-cause linear gets one 5-link chain, multi-cause gets an issue tree with one why-chain per branch) → Explore → Verify (evidence labelled [MEASURED]/[INFERRED]) → Red Team (inversion + tripwires) → System Map → Bias Check (+ base-rate) → Synthesize (bootstrapping pass for estimates) → Self-Critique → Finalize.
The scaffolds carry several evidence-graded guard rails adapted from thinking-framework-skills (an Apache-2.0 library of 63 frameworks graded S/M/P/V/A/C/X) and other reference repos:
Guard | Why | Source |
5 Whys caveat + issue-tree branching | Five Whys is reliable only for simple single-cause linear failures and misleads beyond them (Card 2017) — graded X in the reference library. The scaffold says so and branches multi-cause problems instead. | thinking-framework-skills (Problem Framing) |
| Separate verified facts from inherited conventions so assumptions actually get challenged. | first-principles-thinking-skill |
| Never present an inference as a measurement. | Evidence vs Inference Sort (thinking-framework-skills) |
Red-team tripwires | Premortem's kill criteria: each attack names the observable signal that it is coming true. | Premortem, S/M tier (thinking-framework-skills) |
"When NOT to use" per mode | Every method names where it misleads — mode-mismatch wastes tokens both ways. | thinking-framework-skills (every skill carries one) |
Bootstrapping pass on estimates | Averaging a first estimate with a re-estimate from flipped assumptions measurably beats a single guess (Herzog & Hertwig 2009). | Dialectical Bootstrapping, M tier (thinking-framework-skills) |
Natural-frequency framing | "3 in 1,000" beats "0.3%" for conditional reasoning (Gigerenzer & Hoffrage 1995) — the calibrator warns on bare small percentages. | Natural-Frequency Bayesian Framing, S tier (thinking-framework-skills) |
Not adopted on purpose: ACH (controlled trials found it raises confidence without accuracy — graded X) and Six Thinking Hats-style role lenses (P tier, but the red-team/inversion step already covers the adversarial move). Chain of Draft and token-budget prompting were skipped: the scaffold is a fixed ~1.1k-token cost, and compressing it trades away the very structure being enforced.
Not published to PyPI yet. Install from source:
git clone https://github.com/vipera-iso/thinking-mcp.git thinking-mcp && cd thinking-mcp
uv venv .venv && uv pip install -e .One dependency: mcp. Python ≥ 3.10.
Once published to PyPI, replace the command/args below with "command": "uvx", "args": ["thinking-mcp"] — no clone needed.
The server speaks stdio (how every MCP host launches local servers). Point your agent at the binary and it gets the think tools:
claude mcp add thinking -- /path/to/thinking-mcp/.venv/bin/thinking-mcp{
"mcpServers": {
"thinking": {
"command": "/path/to/thinking-mcp/.venv/bin/thinking-mcp"
}
}
}{
"mcp": {
"thinking": {
"type": "local",
"command": ["/path/to/thinking-mcp/.venv/bin/thinking-mcp"],
"enabled": true
}
}
}{
"mcpServers": {
"thinking": {
"command": "/path/to/thinking-mcp/.venv/bin/thinking-mcp",
"args": ["--log-level", "error"]
}
}
}It also serves Streamable HTTP for clients without stdio support:
thinking-mcp --http --port 8000 (endpoint :8000/mcp).
Drop .cursorrules into your project so the host AI knows when it must
call think.
Tool | What it does |
| Opens a session and returns the protocol scaffold (not the answer) |
| Takes the JSON response → validates → formats (+ advisory |
| Inspects session state for debugging |
| Lists modes and their scaffold cost |
| Verifies a conclusion: the server runs the refutation itself when the layer is on, otherwise returns prompts |
| Takes the refutation / samples back → verdict + agreement |
The /think <problem> prompt drives the flow: think → reason → think_submit.
think_submit -> validate -- OK --> format + return result
|
FAIL --> { status: "invalid", errors: [...], retry_count: 1 }
| host AI fixes it -> submits again
+-- after 2 failures --> "best_effort" with validation_errorsAfter the retries run out the server does not pretend the result is valid: the status
becomes best_effort and the structural errors are returned verbatim.
think_verify)Structure enforcement is not the same as being right. think_verify adds two passes that
make the model do independent work:
Pass | What it does |
A. Refutation | A fresh-context pass that never sees the reasoning chain gets only the conclusion and its evidence, and is told to break it. The fresh context is the mechanism — anchoring is the failure mode targeted. |
B. Self-consistency | N answers to the raw problem, majority-voted, so you can see whether the answer is even reproducible. |
MCP was supposed to let the server initiate these calls itself through sampling
(session.create_message). That does not work here: on mcp 2.3.0 both the stdio and the
Streamable HTTP transports raise
NoBackChannelError: Cannot send 'sampling/createMessage':
this transport context has no back-channel for server-initiated requests.— neither transport carries a channel for server-initiated requests, and sampling is deprecated as of 2026-07-28 (SEP-2577). So the server builds the prompts and parses the results, and the host executes them. No API key is involved either way.
The server cannot enforce that the host ran the refutation in a fresh context. A host
that answers inline from its existing chain gets a weaker version of pass A. The prompt
says so, and the returned output says so too (cannot_enforce).
Neither pass is a judge: A is a model opinion that can reject a correct conclusion, and B
measures reproducibility, not correctness — a confidently wrong answer repeated N times is
still wrong. Both caveats are attached to every result, and when nothing usable comes back
the status is verification_failed with the conclusion labelled UNVERIFIED, never a
pretend-success.
Everything above is $0 and needs no key. This layer is the exception, and it is opt-in: with no keys configured it does not exist, and the responses are byte-identical to the version that had no layer at all.
What it adds when configured:
Pass | Fixes | Effect on the result |
Audit ( | "the validator cannot tell a genuine counter from a fake one" | attaches |
Probes ( | a scaffold that cannot know the problem's domain | appends |
Verification ( | "the server cannot enforce a fresh context" | the server calls the model itself; |
Keys are read from the environment, or from an existing env file — by default
~/.agentmemory/.env (0600, outside git), so the keys agentmemory already holds are
reused instead of copied:
Variable | Meaning |
|
|
| Env file to read (default |
| Comma/space separated key pool for the OpenAI-compatible provider |
| Key pool for the Gemini provider |
| Singular fallbacks, reused from agentmemory |
| Singular fallbacks for the second provider |
| Per-call timeout in seconds (default 60) |
| Switch one pass off ( |
Agnes (agnes-3.0-flash) is tried first and Gemini (gemini-3.8-flash) is the fallback.
Free tiers rate-limit per key, so a key pool is used: on a 429/5xx the current key is
drained and the next one is tried immediately, which is how "12 rate-limited Gemini
keys" becomes one dependable fallback. When every key of every provider fails, the pass
reports unavailable with the reason, and the submission is unaffected.
Measured on this machine with agnes-3.0-flash (free tier):
Call | Latency | Notes |
probes ( | ~7 s | one call, only when the layer is on |
audit ( | ~9 s | 586 prompt + 458 completion tokens on a standard payload |
refutation ( | ~4 s | plus ~5 s per consistency sample |
Turn it off per pass (THINKING_LLM_PROBES=0) or entirely (THINKING_LLM=0).
A judge is an opinion, not ground truth — it can call a correct answer hollow. Every
quality block says so, and nothing in it can change status.
The judge can contradict itself. A live run returned score: 1.0 with
verdict: "hollow". The contradiction is reported (inconsistent), never averaged
away: picking one of the two numbers would be inventing a measurement.
Probes cost tokens on every think, including on problems the protocol already
handles well.
Self-consistency needs ≥2 samples. One reply is not a majority vote, so the server
refuses to run a single sample rather than report agreement: 1.0 from one opinion.
Keys never leave the machine and never reach a tool response — asserted in tests.
The host AI can still write a fake counter. The structural validator cannot tell — and
deliberately does not try. With the optional layer off there is no LLM in the loop at all;
with it on, the quality block is a second opinion attached to the result, never a gate.
Validation does not measure quality. It measures structure. The host AI can still write a fake counter. But without structural enforcement, it skips the step entirely.
DEEP, for example, requires: ≥3 assumptions each labelled [TRUTH]/[ASSUMPTION], a
root_cause object with single_cause + branches (1 branch × 5 links if linear,
≥2 branches × 3 links if an issue tree), ≥2 red-team attacks each with a
what_would_change_my_mind and a tripwire, evidence labelled
[MEASURED]/[INFERRED], ≥3 bias checks, and ≥1 piece of disconfirming evidence.
Calibration only warns, never rewrites: confidence: 0.95 with thin evidence returns
a warning and leaves 0.95 untouched — rewriting it would invent a number.
agnes-3.0-flash over its OpenAI-compatible API, all 26 tasks in eval/tasks.jsonl,
concurrency 2. Raw output is committed in eval/results/.
.venv/bin/python eval/compliance.py --concurrency 2Two complete runs are committed: the baseline (20261006-123628, 10-step deep scaffold) and the guard-rails run (20261006-143122, 11-step deep with all the guards above). The tables show both where they differ; where only one number is given it is the guard-rails run.
Metric | Baseline | Guard rails |
Valid on first submission | 18 / 26 (69%) | 13 / 26 (50%) |
Valid after retry (final) | 25 / 26 (96%) | 25 / 26 (96%) |
Ran out of retries | 1 / 26 (4%) | 1 / 26 (4%) |
Non-JSON replies | 5, across 4 tasks | 4 |
By mode:
mode | n | first-try (base → rails) | final ok (base → rails) |
quick | 3 | 100% → 100% | 100% → 100% |
standard | 16 | 69% → 50% | 100% → 94% |
deep | 7 | 57% → 29% | 86% → 100% |
Baseline | Guard rails | |
Protocol correct | 8 / 8 | 7 / 8 |
Direct correct | 8 / 8 | 8 / 8 |
The regression is math-widgets, and the raw log shows exactly why: the model submitted
confidence: 0.9+ backed by one piece of evidence, was rejected twice by the pre-existing
">0.9 with thin evidence" rule, and exhausted its retry budget. The failure is a retry
mechanics problem, not a guard misfiring — the rule worked as designed, the model just
repeated the same mistake instead of adding evidence or lowering confidence. The flipped
task also swapped: baseline exhausted on debug-useeffect-leak (deep), guard rails run
recovers it. n=8 is far too small to read either flip as signal.
Metric | Baseline | Guard rails |
Protocol tokens | 90,003 | 113,879 |
Protocol host calls | 37 | 41 |
Direct tokens | 19,058 | 18,120 |
Ratio | 4.72× | 6.28× |
Average latency | 50.1 s / task | 61.2 s / task |
Average scaffold | 539 tokens | 715 tokens |
Shows: adding structure costs compliance. The 11-step deep scaffold with mandatory labels and the issue-tree shape cut first-try validity from 69% to 50% overall, and from 57% to 29% in deep — the model needs more retries to produce the richer shape. The retry loop still lands at 96% final validity, and deep final validity went 86% → 100%.
Shows: the new calibrator warnings fire on real output — e.g. arch-monolith-split
was told to restate "1%" as "10 in 1,000". They are advisory, so they cost tokens but
cannot fail a submission.
Does not show a correctness change. 7/8 vs 8/8 on 8 regex-scored tasks is one retry mechanics failure, not evidence either way. The honest headline is unchanged: this measurement supports structure enforcement, not accuracy improvement, and the extra structure is paid for in tokens (6.28×) and latency (61 s/task).
❌ Does not make the AI smarter — only stops it skipping steps
⚠️ Semantic quality needs the optional LLM layer; the structural validator alone cannot tell a genuine counter from a fake one
❌ Cannot force 100% compliance — a model that ignores protocols gets nothing from this
❌ Guard rails have a compliance price: first-try validity fell 69% → 50% (deep 57% → 29%) because the richer shape is harder to produce on the first attempt
❌ Deep mode does not suit every question (scaffold token cost)
⚠️ The eval needs a real host AI to measure compliance; the server itself produces no answer
⚠️ think_verify passes are opinions, not a judge — the optional layer removes the
fresh-context caveat (the server calls the model itself) but not the opinion one
uv venv .venv && uv pip install -e ".[dev]"
.venv/bin/python -m pytest -q # 216 tests, including e2e over real stdioThe LLM layer is tested two ways, both offline: scripted transports for rotation, fallback and redaction, and an end-to-end run of the real stdio server against a stub provider on localhost (real HTTP, real headers, real JSON — no key, no network):
.venv/bin/python -m pytest tests/test_llm.py tests/test_llm_e2e.py -qThe end-to-end tests spawn the real server over stdio and drive it with mcp.Client —
the same path Cursor / Claude Desktop take.
MIT
Open a thinking session and get the protocol scaffold for a question. It does NOT answer the question — it only builds the structure the host AI reasons through. With an LLM layer configured it also appends domain-specific probes for this problem.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | auto | |
| context | No | ||
| problem | 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. It does disclose two useful traits: it produces a scaffold rather than an answer, and an optional LLM layer appends domain probes. It omits session lifecycle facts (whether the session must later be submitted/verified, whether state persists, or any cost/latency from the LLM layer).
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?
Three short sentences, front-loaded with the core action and immediately followed by the key clarification of what it does not do. Slightly more economy is possible in the final sentence about the LLM layer, but there is little waste.
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 explained. However, for a tool sitting at the head of a multi-step workflow (think -> submit -> verify), the description omits the workflow position and leaves all three parameters undocumented, which is thin for a 3-param tool.
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% for all three parameters. The description never mentions mode (with its auto/quick/standard/deep enum), context, or what form "problem" should take, so it fails to compensate for the documentation gap. Only the concept of a "question" loosely maps to the required problem param.
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?
The description uses a specific verb+resource ("open a thinking session", "get the protocol scaffold") and explicitly states the inverse ("does NOT answer the question"), which separates it from the answering/verifying siblings. It does not, however, name any sibling such as think_submit or think_verify to route the agent explicitly.
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 explicit when-to-use or when-not-to-use guidance relative to the five sibling tools. Usage is only implied by the notion of "opening" a session first, leaving the agent to infer that this precedes think_submit/think_verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the thinking modes and their scaffold cost.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 burden. The verb 'list' reasonably signals a read-only, non-destructive operation, and it discloses one return dimension (scaffold cost). However, it says nothing about permissions, caching, or side effects.
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 front-loaded sentence with zero padding. It conveys subject and scope immediately and nothing is wasted.
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?
With zero parameters and an output schema present, the description need not explain return values, and it is adequate for a trivial discovery tool. The unexplained jargon 'scaffold cost' is the main gap, though the output schema presumably defines it.
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?
The tool takes zero parameters, which is the baseline-4 case. There is nothing for the description to clarify beyond what the empty schema already shows.
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 (list) and resource (thinking modes/templates) plus an attribute of interest (scaffold cost). This clearly distinguishes it from the operational siblings (think, think_submit, think_verify), which perform or manage thinking rather than enumerate modes. The only weakness is that 'templates' in the name vs 'thinking modes' in the description creates mild terminology drift.
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 implied: call it when you need to discover available thinking modes and their costs. There is no explicit when/when-not guidance and no alternative sibling is named for comparison, so the agent must infer the discovery role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a thinking session (for debugging).
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| 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 implies a read-style diagnostic but never confirms read-only behavior, permissions, side effects, or session-scoping constraints.
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 short sentence with no filler and the purpose front-loaded. Brevity is appropriate, though it borders on under-specification rather than tight conciseness.
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. However, with no annotations and an undocumented required parameter, the description is too thin for an agent to invoke this tool confidently without inspecting the schema.
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% and the description adds nothing about the single required parameter. It does not explain what a session_id is, its format, or where to obtain one, leaving the agent to guess.
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 (inspect) and resource (thinking session), so an agent can tell it queries session state. It does not, however, differentiate itself from siblings like think_verify or think_submit, leaving relative purpose 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?
The only guidance is the parenthetical '(for debugging),' which implies a diagnostic use case but names no alternatives and no explicit when/when-not conditions. An agent cannot tell from this whether to prefer it over think_verify or think_submit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit the JSON response for a session. Validates the structure and returns the formatted result. If the structure is wrong, returns the error list so the host AI can fix it and submit again. With an LLM layer configured the result also carries an advisory quality audit of the substance — it can never change the status.
| Name | Required | Description | Default |
|---|---|---|---|
| response | Yes | ||
| session_id | 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 validation-on-submit, the error-list-on-failure contract with a retry path, and that the LLM quality audit is advisory and cannot change status. It omits whether submission terminates/mutates session state, idempotency, and permission needs.
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?
Three tight sentences that front-load the core action (submit) and then layer failure handling and the quality-audit caveat. No filler, though the third sentence's conditional framing adds length without operational 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 not explaining return values is acceptable, and the description does cover the error and advisory-audit branches. The gap is on the input side: it never tells the agent how to construct the payload it will be judged on.
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% for both parameters, and `response` is a free-form nested object with additionalProperties=true. The description says the structure is validated but never explains what structure is expected or that it must come from a template (e.g. via think_list_templates) — the single most important thing an agent needs here.
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 clear verb+resource: 'Submit the JSON response for a session', with the added scope of validation and result formatting. It does not, however, distinguish itself from the sibling think_verify_submit, which by name implies a similar submission flow.
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 implied by the retry loop ('if the structure is wrong... fix it and submit again'), which tells the agent this is the terminal submit step. But it never says when to prefer it over think_verify_submit or how it relates to think_status, and no prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a conclusion independently. With an LLM layer configured the server runs the adversarial refutation pass ITSELF in its own fresh context — it never saw the reasoning chain — plus optionally N self-consistency samples; set server_side=false to get only the prompts for the host to run. Without a configured layer it always returns prompts and says nothing ran.
| Name | Required | Description | Default |
|---|---|---|---|
| counter | No | ||
| problem | Yes | ||
| samples | No | ||
| evidence | No | ||
| conclusion | Yes | ||
| server_side | 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 and does well: it discloses that the verifier runs in a fresh context that never saw the reasoning chain, that optional N self-consistency samples are run, and that without a configured layer nothing executes and only prompts return. It omits any permission, cost, or side-effect notes, but the core behavioral profile is clear.
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?
The behaviorally most important fact (independent verification in a fresh context) is front-loaded, and the server_side toggle and fallback follow. The single dense paragraph is clause-heavy but every clause conveys a distinct behavior.
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 documented, and the description covers the server-side vs host-side execution split and the degraded no-layer mode. Undocumented input parameters (problem, conclusion, evidence) are the remaining gap.
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% across 6 parameters, so the description must compensate. It explains server_side and samples meaningfully and implicitly references the adversarial counter, but problem, conclusion, and evidence remain undefined in both places. Partial compensation only.
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: 'Verify a conclusion independently'. The adversarial refutation and self-consistency sampling detail makes the operation concrete. It stops short of distinguishing itself from the closely named sibling think_verify_submit, which an agent would likely confuse it with.
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?
Gives clear usage conditions: with a configured LLM layer it runs server-side automatically, and setting server_side=false returns prompts for the host to run. It also covers the no-layer fallback. It does not state when to choose this over think_verify_submit, so sibling routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit the refutation reply (and any self-consistency samples) gathered from think_verify. Validates and formats the verdict. Reports verification_failed instead of pretending a pass ran when the replies are unusable.
| Name | Required | Description | Default |
|---|---|---|---|
| problem | Yes | ||
| conclusion | Yes | ||
| refutation | No | ||
| self_consistency | 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 burden. It helpfully discloses validation, formatting, and a failure mode ('verification_failed instead of pretending a pass ran'), but does not state side effects, persistence, auth needs, or what happens on success.
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?
Three tight sentences, front-loaded with the action verb and source tool. Each sentence adds distinct value: purpose, validation behavior, and failure reporting. No obvious waste, though it could be slightly more compact.
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 explained. However, with four parameters at 0% coverage and no annotations, the description leaves required parameter meaning, side effects, and workflow constraints largely unexplained. The failure-mode note helps but is not enough.
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 mentions refutation and self_consistency, but omits the required problem and conclusion parameters and gives no format, default, or constraint details for any of the four inputs.
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 'Submit' and resource 'refutation reply (and any self-consistency samples) gathered from think_verify', and clarifies it validates and formats the verdict. It names the sibling think_verify as the source of inputs, though it does not explicitly distinguish itself from think_submit.
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 implied: use after think_verify when refutation replies have been gathered. There is no explicit when-not guidance or comparison to alternatives like think_submit or think_verify, nor any stated prerequisites.
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.0thinkthink_list_templatesthink_statusthink_submitthink_verifythink_verify_submitScored across 6 tools
Each tool maps to a distinct step in a session lifecycle (list, open, submit, status, verify, verify_submit), and descriptions clearly separate think (build scaffold) from think_verify (independent refutation). The only real overlap is think_submit vs think_verify_submit, both of which accept JSON, but their pairing with the parent tool is spelled out.
All tools use snake_case with a consistent think_ prefix and a predictable verb_noun shape (think_list_templates, think_submit, think_status, think_verify, think_verify_submit). The single bare 'think' is the primary entry action and does not break readability.
Six tools is well-scoped for a thinking-session protocol: one entry point plus list, submit, status, verify, and verify_submit. Each tool earns its place with no redundancy.
The lifecycle is largely covered: discovery, session creation, submission, inspection, independent verification, and verdict submission. Minor gaps exist, e.g. no explicit session abort/close or list-sessions operation, but agents can work around these.
Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP.
Autonomous agent guardrails, bash sandboxing, MCP rugpull diffing & prompt firewalls.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
