verifiable-thinking-mcp

Name: verifiable-thinking-mcp
Author: CoderDayton

by CoderDayton

Overview Schema Related Servers Score Discussions

TypeScript

Your LLM is confidently wrong 40% of the time on reasoning questions. This fixes that.

npm version codecov License: MIT

15 trap patterns detected in <1ms. No LLM calls. Just pattern matching.

Quick Start • Features • Trap Detection • API

┌────────────────────────────────────────────────────────────────┐
│ "A bat and ball cost $1.10. The bat costs $1 more..."          │
│                             ↓                                  │
│ TRAP DETECTED: additive_system                                 │
│ > Don't subtract $1 from $1.10. Set up: x + (x+1) = 1.10       │
│                             ↓                                  │
│ Answer: $0.05 (not $0.10)                                      │
└────────────────────────────────────────────────────────────────┘

Quick Start

npx -y verifiable-thinking-mcp

Add to Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "verifiable-thinking": {
      "command": "npx",
      "args": ["-y", "verifiable-thinking-mcp"]
    }
  }
}

Features


🎯 Trap Detection	15 patterns (bat-ball, Monty Hall, base rate) caught before reasoning starts
⚔️ Auto-Challenge	Forces counterarguments when confidence >95%—no more overconfident wrong answers
🔍 Contradiction Detection	Catches "Let x=5" then "Now x=10" across steps
🌿 Hypothesis Branching	Explore alternatives, auto-detects when branches confirm/refute
🔢 Local Math	Evaluates expressions without LLM round-trips
🗜️ Smart Compression	49% token savings with telegraphic + sentence-level compression
⚡ Real Token Counting	Tiktoken integration—3,922× cache speedup, zero estimation error

Token Efficiency

Every operation counts. Verifiable Thinking uses real token counting (tiktoken) and intelligent compression to cut costs by 50-60% without sacrificing reasoning quality.

// Traditional reasoning: ~1,350 tokens for 10-step chain
// Verifiable Thinking: ~580 tokens (49–57% savings)

// Real token counting (not estimation)
countTokens("What is 2+2?")  // → 7 tokens (not 3)
// Cache speedup: 3,922× faster on repeated strings

// Compress before processing (not just storage)
scratchpad({
  operation: "step",
  thought: "Long analysis...",  // 135 tokens → 72 tokens
  compress: true
})

// Budget controls
scratchpad({
  warn_at_tokens: 2000,     // Soft warning
  hard_limit_tokens: 5000   // Hard stop
})

At scale: 1,000 reasoning chains/day = $4,193/year saved (at GPT-4o pricing).

See docs/token-optimization.md for architecture details and benchmarks.

How It Works

// Start with a question—trap detection runs automatically
scratchpad({
  operation: "step",
  question: "A bat and ball cost $1.10...",
  thought: "Let ball = x, bat = x + 1.00",
  confidence: 0.9
})
// → Returns trap_analysis warning

// High confidence? Auto-challenge kicks in
scratchpad({ operation: "step", thought: "...", confidence: 0.96 })
// → Returns challenge_suggestion: "What if your assumption is wrong?"

// Complete with spot-check
scratchpad({ operation: "complete", final_answer: "$0.05" })

Trap Detection

Pattern	What It Catches
`additive_system`	Bat-ball, widget-gadget (subtract instead of solve)
`nonlinear_growth`	Lily pad doubling (linear interpolation)
`monty_hall`	Door switching (50/50 fallacy)
`base_rate`	Medical tests (ignoring prevalence)
`independence`	Coin flips (gambler's fallacy)

Pattern	Trap
`additive_system`	Subtract instead of solve
`nonlinear_growth`	Linear interpolation
`rate_pattern`	Incorrect scaling
`harmonic_mean`	Arithmetic mean for rates
`independence`	Gambler's fallacy
`pigeonhole`	Underestimate worst case
`base_rate`	Ignore prevalence
`factorial_counting`	Simple division
`clock_overlap`	Assume 12 overlaps
`conditional_probability`	Ignore conditioning
`conjunction_fallacy`	More detail = more likely
`monty_hall`	50/50 after reveal
`anchoring`	Irrelevant number influence
`sunk_cost`	Past investment bias
`framing_effect`	Gain/loss framing

Tools

scratchpad — the main tool with 11 operations:

Operation	What It Does
`step`	Add reasoning step (trap priming on first)
`complete`	Finalize with auto spot-check
`revise`	Fix earlier step
`branch`	Explore alternative path
`challenge`	Force adversarial self-check
`navigate`	View history/branches

Operation	Purpose
`step`	Add reasoning step
`complete`	Finalize chain
`revise`	Fix earlier step
`branch`	Alternative path
`challenge`	Adversarial self-check
`navigate`	View history
`spot_check`	Manual trap check
`hint`	Progressive simplification
`mistakes`	Algebraic error detection
`augment`	Compute math expressions
`override`	Force-commit failed step

Other tools: list_sessions, get_session, clear_session, compress

vs Sequential Thinking MCP

	Sequential Thinking	Verifiable Thinking
Trap detection	❌	15 patterns
Auto-challenge	❌	>95% confidence
Contradiction detection	❌	✅
Confidence tracking	❌	Per-step + chain
Local compute	❌	✅
Token budgets	❌	Soft + hard limits
Real token counting	❌	Tiktoken (3,922× cache speedup)
Compression	❌	49–57% token savings

Sequential Thinking is ~100 lines. This is 22,000+ with 1,967 tests.

See docs/competitive-analysis.md for full breakdown.

Development

git clone https://github.com/CoderDayton/verifiable-thinking-mcp.git
cd verifiable-thinking-mcp && bun install
bun run dev      # Interactive MCP Inspector
bun test         # 1,967 tests

License

MIT

Report Bug · Request Feature

Available Tools

5 tools

clear_sessionC

Clear session(s) to free memory

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Session ID to clear (omit for all)
`all`	Yes	Clear all sessions

TDQS

C2.9/5.0

Behavior2/5

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 mentions 'free memory', which hints at a destructive operation, but fails to disclose critical behavioral traits such as whether clearing is reversible, what data is lost, permission requirements, or side effects. This is inadequate for a tool that likely modifies state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and purpose, making it easy to parse quickly. Every word earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive operation with 2 parameters) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral risks, return values, or error conditions, leaving significant gaps for the agent to operate safely and effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond implying that clearing sessions frees memory, but it doesn't explain parameter interactions (e.g., how 'session_id' and 'all' relate) or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Clear session(s) to free memory' clearly states the action (clear) and resource (session(s)), with a specific purpose (free memory). It distinguishes from siblings like 'get_session' or 'list_sessions' by indicating a destructive operation, though it doesn't explicitly contrast with 'scratchpad' or 'compress'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'scratchpad' or 'compress', which might also manage memory. The description implies usage for freeing memory but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on general knowledge.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compressB

CPC-style sentence-level compression. TF-IDF + NCD scoring, coreference/causal chains, filler removal. 10× faster than token-level LLM compression. Keeps query-relevant sentences.

ParametersJSON Schema

Name	Required	Description
`context`	Yes	Text to compress
`query`	Yes	Focus query
`target_ratio`	Yes	Target ratio (0.5=50%)
`max_tokens`	No	Max tokens (alternative to ratio)
`boost_reasoning`	Yes	Boost reasoning keywords
`use_ncd`	Yes	Use NCD (gzip) scoring
`enforce_coref`	Yes	Keep pronoun antecedents
`enforce_causal`	Yes	Keep causal premises
`remove_fillers`	Yes	Remove filler phrases

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context about the compression method (TF-IDF + NCD scoring) and performance (10× faster), but lacks details on permissions, rate limits, error handling, or output format. For a tool with 9 parameters and no annotations, this is a moderate gap, scoring at the baseline of adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with key information in the first part. It uses technical terms efficiently (e.g., 'CPC-style,' 'TF-IDF + NCD scoring') without unnecessary elaboration. However, it could be slightly more structured (e.g., separating performance claims from functional details), keeping it from a perfect 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters, no annotations, no output schema), the description is moderately complete. It covers the compression approach and performance but lacks details on output format, error cases, or integration context. For a tool with rich input schema but no other structured data, this is adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any specific parameter semantics beyond what's in the schema (e.g., it doesn't explain how 'target_ratio' interacts with 'max_tokens' or detail the algorithms). With high schema coverage, the baseline is 3, and the description doesn't compensate further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs 'CPC-style sentence-level compression' with specific techniques mentioned (TF-IDF + NCD scoring, coreference/causal chains, filler removal). It distinguishes the tool by mentioning it's '10× faster than token-level LLM compression' and 'Keeps query-relevant sentences,' giving a clear sense of what it does. However, it doesn't explicitly differentiate from sibling tools (which appear unrelated to compression), so it doesn't reach a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It mentions it's faster than 'token-level LLM compression,' which implies a comparison, but doesn't name specific alternatives or provide explicit when/when-not scenarios. With no usage context provided, this falls to a minimal score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sessionC

Get session: full/summary/compressed format

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Session ID (uses active if omitted)
`format`	Yes	Format: full (all), summary (overview), compressed (key only)	summary
`branch_id`	No	Filter by branch ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but provides minimal behavioral context. It mentions format options but doesn't disclose what data each format returns, whether this requires authentication, if there are rate limits, or how the 'active' session fallback works. The description is insufficient for a tool with no 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single phrase with zero wasted words. The description is front-loaded with the core purpose and includes essential format information in a compact format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'session' represents in this context, what data is returned in each format, or how the tool behaves when session_id is omitted. The description should provide more context given the lack of structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value by mentioning format options, but doesn't provide additional semantic context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'session', with the additional detail about format options (full/summary/compressed). It distinguishes from siblings like 'clear_session' (destructive) and 'list_sessions' (multiple sessions), but doesn't explicitly contrast with 'compress' or 'scratchpad'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'list_sessions' or 'scratchpad'. The description mentions format options but doesn't explain when each format is appropriate or any prerequisites for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_sessionsB

List active sessions with counts/branches

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It lacks details on permissions needed, rate limits, whether it's read-only or mutating, pagination, or error handling. This leaves significant gaps for a tool that likely interacts with session data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action ('List active sessions') and adds clarifying detail ('with counts/branches'). There is no wasted verbiage, making it appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and the tool's potential complexity (listing sessions with counts/branches), the description is incomplete. It doesn't explain what 'counts/branches' means, the format of returned data, or behavioral aspects like safety or performance. This leaves the agent with insufficient context for reliable use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline for this case. No additional value is required beyond stating the tool's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('active sessions'), and specifies the scope ('with counts/branches'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_session' or 'clear_session', which would require more specific comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_session' (for a single session) or 'clear_session' (for deletion). It implies usage for listing active sessions but offers no context about prerequisites, timing, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scratchpadC

Structured reasoning w/verification, trap detection, self-challenge. []=optional

OPS (required: operation=): step thought= [question=1st] [confidence=] [verify=] [domain=math|logic|code|general] [compress=true]→add step. Auto-verifies when chain >3 steps. complete [final_answer=] [summary=]→finalize+spot-check revise target_step= thought= [reason=]→fix step branch thought= [from_step=] [hypothesis=] [success_criteria=]→fork path navigate view=history|branches|step|path [step_id=] [limit=10]→inspect augment text= [store_as_step=false]→compute+inject math results hint [expression=] [reveal_count=] [cumulative=true] [reset=false]→progressive hints (auto-continues) mistakes text=→check algebraic errors spot_check question= answer=→check for common reasoning traps challenge [target_claim=] [challenge_type=all]→adversarial self-check override failed_step= [reason=]→force-commit failed step

DEFAULTS: session_id=auto confidence_threshold=0.8 token_budget=3000 augment_compute=true compress=true

FLOW: 1.step(question="...",thought="...")→primes trap detection for the question 2.step(thought="...")×N→auto-verify, auto-compress, confidence-drift detection, consistency checks 3.[optional]challenge()→adversarial self-check of claims 4.complete(final_answer="...")→auto spot-check against common traps 5.if status=review→revise per reconsideration.suggested_revise

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Operation to perform
`confidence_threshold`	No	Chain confidence threshold to suggest completion (default: 0.8)
`token_budget`	No	Max tokens before auto-compressing new steps (default: 3000)
`warn_at_tokens`	No	Warn when cumulative session tokens exceed this threshold (soft limit, cost control)
`hard_limit_tokens`	No	Hard stop when cumulative session tokens exceed this threshold. Returns budget_exhausted status and blocks further operations.
`thought`	No	Current reasoning/analysis (step/branch/revise)
`purpose`	No	Step category
`outcome`	No	Result or conclusion from this step
`confidence`	No	Confidence in this step (0-1). Contributes to chain average.
`context`	No	Prior context or findings
`verify`	No	Run domain verification. Auto-enabled for chains >3 steps. Set to false to disable.
`domain`	No
`local_compute`	No	Try local compute for math (default: false)
`augment_compute`	No	Auto-inject computed values into thought (default: true)
`compress`	No	Compress thought before storing (default: true)
`compression_query`	No	Query for context-aware compression
`max_step_tokens`	No	Max tokens for this step. Rejects if exceeded (default: no limit)
`force_large`	No	Allow step even if it exceeds max_step_tokens (default: false)
`preconditions`	No	Assumptions that MUST be true for this step (e.g., 'x > 0', 'file exists')
`view`	No	What to view: history (all steps), branches (list), step (specific), path (lineage)
`step_id`	No	Step number to view
`branch_id`	No	Filter history by branch
`limit`	No	Max steps to return (default: 10)
`from_step`	No	Step to branch from (default: current)
`branch_name`	No	Human-readable branch name
`hypothesis`	No	Falsifiable hypothesis this branch will test (e.g., 'Assume X is prime')
`success_criteria`	No	What observation proves/disproves this hypothesis
`target_step`	No	Step number to revise
`reason`	No	Why revising this step / Why overriding verification
`summary`	No	Final summary/conclusion
`final_answer`	No	The answer/result
`question`	No	Original question. On step: enables trap priming and stores for auto spot-check. On complete: enables spot-check.
`text`	No	Text containing math expressions to compute and inject (augment/mistakes)
`system_context`	No	System prompt context for domain filtering
`store_as_step`	No	Store augmented result as a reasoning step (default: false)
`acknowledge`	No	Confirm you understand verification failed but want to proceed
`failed_step`	No	Step number that failed verification
`expression`	No	Math expression to simplify. Omit to continue from previous hint in session.
`reveal_count`	No	Number of steps to reveal. Omit to auto-increment when continuing.
`cumulative`	No	Show all steps up to reveal_count (true) or just the nth step (false). Default: true
`reset`	No	Reset hint state and start from beginning (default: false)
`answer`	No	The proposed answer to check for trap patterns
`challenge_type`	No	Type of challenge to generate (default: all)
`target_claim`	No	Specific claim to challenge (optional - if omitted, extracts claims from steps)

TDQS

C2.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are empty, so the description carries the full burden. It discloses several behavioral traits: auto-verification for chains >3 steps, auto-compression, confidence-drift detection, consistency checks, and status-driven actions (e.g., 'verification_failed→revise|branch|override'). It also mentions defaults like 'confidence_threshold=0.8' and 'token_budget=3000'. However, it lacks details on error handling, performance limits, or side effects, leaving some gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly verbose and poorly structured, with dense sections like 'OPS', 'DEFAULTS', 'STATUS→ACTION', and 'FLOW' that mix operational details, defaults, and usage flow without clear separation. Sentences are fragmented (e.g., 'Auto-verifies when chain >3 steps.'), and it includes unnecessary symbols like '[]=optional'. It is not front-loaded with a clear purpose, making it difficult to parse efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity (44 parameters, no output schema, no annotations), the description attempts to cover behavior and flow but falls short. It explains operations and status transitions but lacks details on return values, error responses, or integration with sibling tools. Without an output schema, the description should ideally explain what the tool returns, but it does not, leaving gaps in completeness for such a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 98%, so the schema already documents most parameters extensively. The description adds minimal semantic value beyond the schema: it lists operation types (e.g., 'step', 'complete') and hints at parameter usage in the flow (e.g., 'step(question="...",thought="...")'), but does not explain parameter interactions or provide examples. With high schema coverage, the baseline is 3, and the description does not significantly compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with 'Structured reasoning w/verification, trap detection, self-challenge', which provides a vague high-level purpose but lacks a specific verb-resource combination. It then dives into operational details without clearly stating what the tool fundamentally does (e.g., manage a reasoning session, perform stepwise analysis). The title is null, and the name 'scratchpad' is generic, making the purpose unclear without reading the entire description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'FLOW' section with numbered steps (e.g., '1.step(question="...",thought="...")→primes trap detection'), which implies usage in a sequential reasoning process. However, it does not explicitly state when to use this tool versus alternatives like 'clear_session' or 'compress', nor does it provide context on prerequisites or exclusions. The guidance is implied through the flow but not clearly articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.6.1Mar 13, 2026
- First observedclear_session
- First observedcompress
- First observedget_session
- First observedlist_sessions
- First observedscratchpad

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation4/5

Most tools have distinct purposes: clear_session, get_session, and list_sessions handle session management, while compress and scratchpad focus on content processing and reasoning. However, scratchpad's extensive OPS (e.g., step, complete, revise) could overlap with compress's compression functionality in handling text, creating minor ambiguity in content manipulation tasks.

Naming Consistency3/5

The main tool names (clear_session, compress, get_session, list_sessions, scratchpad) follow a consistent verb_noun or noun pattern, but scratchpad's OPS include varied formats like step, complete, and navigate without a strict naming convention. This mix of styles within scratchpad reduces overall consistency.

Tool Count5/5

With 5 tools, the server is well-scoped for verifiable thinking, covering session management, compression, and structured reasoning. Each tool serves a clear role without bloat, making the count appropriate for the domain's complexity.

Completeness4/5

The tool set provides comprehensive coverage for verifiable thinking workflows, including session lifecycle (list, get, clear), content compression, and detailed reasoning with verification. Minor gaps might exist in advanced session analytics or integration with external data sources, but core operations are well-covered.

Resources

Need Help?

Related Servers

Related MCP Connectors

strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
ejentum-mcp
io.github.ejentum
Reasoning, code, anti-deception, memory harness MCP tools. Stdio or HTTPS api.ejentum.com/mcp
AI & Machine Learning Knowledge & Memory Code Execution
316
Reasoning Commons
io.github.chenyuan35
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
AI & Machine Learning Knowledge & Memory Autonomous Agents
2
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CoderDayton/verifiable-thinking-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server