How do I use mcp-turtle-noir?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-turtle-noir Start a puzzle about islands" 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.

mcp-turtle-noir

by Yuikij

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

mcp-turtle-noir

MCP server for Turtle Soup (lateral thinking puzzles).

This package is a thin MCP layer over Turtle Noir backend APIs and is designed for stdio transport.

Homepage | 中文文档 | 日本語

Features

start_session: start a new puzzle session
ask_question: ask one question and receive a structured result
give_up_and_reveal: reveal the solution (subject to backend reveal policy)
Multilingual MCP output (zh-CN, en-US, ja-JP) via language
Keeps puzzle solutions on the backend during normal gameplay

Related MCP server: Haiguitang MCP Server

Transport

Supported: stdio
Not included in this package: SSE/HTTP MCP transport

Requirements

Node.js 18+

Install and Run

npx -y mcp-turtle-noir

MCP Client Config

{
  "mcpServers": {
    "turtle-noir": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-turtle-noir"
      ]
    }
  }
}

With environment variables:

{
  "mcpServers": {
    "turtle-noir": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-turtle-noir"
      ],
      "env": {
        "TURTLE_NOIR_API_BASE_URL": "https://turtlenoir.com/api/mcp",
        "TURTLE_NOIR_API_TIMEOUT_MS": "10000",
        "TURTLE_NOIR_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Tools

1) `start_session`

Input (all optional):

{
  "region": "US",
  "keyword": "island",
  "language": "en-US"
}

Output:

{
  "session_id": "...",
  "puzzle_id": "...",
  "title": "...",
  "content": "...",
  "language": "en-US",
  "instruction": "...",
  "translation_instruction": "..."
}

2) `ask_question`

Input:

{
  "session_id": "...",
  "question": "...",
  "language": "en-US"
}

Output:

{
  "session_id": "...",
  "language": "en-US",
  "answer_key": "irrelevant",
  "answer": "Irrelevant",
  "answer_original": "...",
  "short_reason": "...",
  "solved": false,
  "progress": 35,
  "translation_instruction": "..."
}

3) `give_up_and_reveal`

Input:

{
  "session_id": "...",
  "language": "en-US"
}

Output:

{
  "session_id": "...",
  "language": "en-US",
  "title": "...",
  "solution": "...",
  "cta_url": "https://turtlenoir.com",
  "cta_text": "...",
  "translation_instruction": "..."
}

Note: backend may reject reveal if progress is below a threshold (for example progress < 60).

Environment Variables

TURTLE_NOIR_API_BASE_URL (default: https://turtlenoir.com/api/mcp)
TURTLE_NOIR_API_TIMEOUT_MS (default: 10000)
TURTLE_NOIR_API_KEY (optional Bearer token)

Development

npm install
npm run build
node dist/index.js

Quick Start

See QUICKSTART.md.

Chinese Docs

See README.zh-CN.md.

License

MIT. See LICENSE.

Acknowledgements

Official Website: Turtle Noir
Chinese Mirror: 出前一汤

Available Tools

3 tools

ask_questionBInspect

Ask a question for the active session. Detect user language and pass language (zh-CN/en-US/ja-JP).

ParametersJSON Schema

Name	Required	Description
`language`	No	User language for localized response, e.g. zh-CN/en-US/ja-JP
`question`	Yes	Detective question to judge
`session_id`	Yes	Session ID returned by start_session

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided; description adds language detection behavior but lacks disclosure of whether tool is read-only, destructive, or any side effects. No mention of permissions, rate limits, or return behavior.

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?

Single sentence of 14 words, front-loaded with purpose, no filler. Every part is meaningful.

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?

Covers main action and language detail but does not describe return value (e.g., answer, error handling) or how language detection works. With no output schema, more explanation would be helpful.

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?

Description adds value beyond 100% schema coverage by explaining language detection ('Detect user language') and providing examples. Schema describes language parameter but description contextualizes its use.

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?

Specifies verb 'Ask' and resource 'question for the active session'. Clearly distinguishes from sibling tools 'start_session' (initiation) and 'give_up_and_reveal' (different action). However, no explicit differentiation statement.

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?

Implies usage after starting a session, but no explicit when-to-use or when-not-to-use guidelines. Does not mention alternatives or prerequisites.

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

give_up_and_revealAInspect

Give up the current session and reveal the full story. Detect user language and pass language (zh-CN/en-US/ja-JP).

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	User language for localized response, e.g. zh-CN/en-US/ja-JP
`session_id`	Yes	Session ID returned by start_session

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions 'give up' and 'reveal' but does not state whether the action is destructive, what happens to the session, or any side effects. Minimal behavioral context beyond the action itself.

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?

Two sentences, front-loaded with the core action, then the language requirement. No wasted words.

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?

With 2 parameters and no output schema, the description covers the main action and language detection. However, it does not explain what 'reveal the full story' means in terms of output or any side effects. Adequate but not fully complete.

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 coverage is 100% with both parameters described. The description adds 'Detect user language and pass language' which reiterates the schema's language parameter description without adding new meaning. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool ends the session and reveals the full story, with a specific verb and resource. It distinguishes from siblings start_session and ask_question which handle starting and questioning.

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 implies usage when the user gives up and wants the story revealed, but lacks explicit guidance on when not to use it or how it compares to alternatives. No exclusions or alternative tools mentioned.

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

start_sessionCInspect

Start a new Turtle Soup session. Detect user language and pass language (zh-CN/en-US/ja-JP). Optional: region, difficulty, keyword.

ParametersJSON Schema

Name	Required	Description
`region`	No	Optional region code, e.g. US/CN/JP
`keyword`	No	Optional fuzzy keyword on title/surface/tags
`language`	No	User language for localized response, e.g. zh-CN/en-US/ja-JP
`difficulty`	No	Optional difficulty preference

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description must carry full burden. It only mentions session start and parameters, lacking details on side effects, state, or prerequisites.

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?

Two sentences, front-loaded with action. Efficient but could be clearer about the detection behavior.

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?

No output schema, minimal description. Does not explain what a session is, what it returns, or what happens on start. Incomplete for a 4-parameter 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 coverage is 100%, baseline is 3. Description adds little beyond listing parameters; the mention of 'detect user language' could contradict schema which marks language as optional.

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?

Clearly states it starts a new Turtle Soup session and lists parameters, but the phrase 'Detect user language and pass language' is ambiguous about whether detection is automatic or manual.

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 explicit guidance on when to use this tool compared to siblings (ask_question, give_up_and_reveal). Usage is implied but not clarified.

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.

3 tool updatesv1.2.2Jul 29, 2026
- First observedask_question
- First observedgive_up_and_reveal
- First observedstart_session

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-07-29 09:20 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: starting a session, asking a question, and revealing the story. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: start_session, ask_question, give_up_and_reveal. No deviations.

Tool Count5/5

Three tools are appropriate for the simple session lifecycle of a Turtle Soup game. Not too few or too many.

Completeness4/5

Covers the main actions (start, ask, reveal). Minor gap: no explicit non-reveal end or session list, but sufficient for core gameplay.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

smithery-ai-cookbook-python-quickstart
ai.smithery
A simple MCP server built with FastMCP and python
Developer Tools
213
Second server!
com.fenetresurciel.verylongmcp
A non functional MCP server (yet)
Developer Tools
2
acme-todo
com.ritzademo
An MCP server for a simple todo list
Developer Tools App Automation
2
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168

Related MCP Servers

mcp-perplexity
Search RAG Systems
daniel-lxs
A
license
Not graded
quality
C
maintenance
MCP Server for the Perplexity API.
Updated 2 years ago (2025-02-27 16:28 UTC)
66
MIT
Haiguitang MCP Server
Games & Gamification Education & Learning Tools
wangyafu
F
license
B
quality
D
maintenance
An MCP server that allows users to play the 'Turtle Soup' puzzle game with LLMs acting as game hosts, providing tools to access game rules, puzzles, and comprehensive puzzle information.
Updated a year ago (2025-04-08 03:17 UTC)
3
13
-
simple-prompts-mcp
Developer Tools Documentation Access
sinofseven
A
license
Not graded
quality
D
maintenance
A simple MCP server for utilizing prompts defined in YAML files.
Updated a year ago (2025-05-15 17:18 UTC)
MIT
TuringWell MCP Serverofficial
Knowledge & Memory Search Autonomous Agents
Deep-Insight-Labs
A
license
A
quality
C
maintenance
MCP server for TuringWell, the agent-native Q&A platform for executable, verifiable fixes.
Updated 5 months ago (2026-04-06 15:44 UTC)
16
7 npm
MIT

mcp-turtle-noir

Features

Transport

Requirements

Install and Run

MCP Client Config

Tools

1) start_session

2) ask_question

3) give_up_and_reveal

Environment Variables

Development

Quick Start

Chinese Docs

License

Acknowledgements

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

mcp-perplexity

Haiguitang MCP Server

simple-prompts-mcp

TuringWell MCP Serverofficial

1) `start_session`

2) `ask_question`

3) `give_up_and_reveal`