thinking-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| thinkB | 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. |
| think_submitB | 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 |
| think_statusC | Inspect a thinking session (for debugging). |
| think_list_templatesA | List the thinking modes and their scaffold cost. |
| think_verifyA | 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. |
| think_verify_submitB | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| think | Run /think <problem> to force the host AI through the protocol instead of answering directly. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.