thinkspace-mcp
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., "@thinkspace-mcpSend this summary to my ThinkSpace inbox."
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.
thinkspace-mcp
An MCP server that sends notes from your AI conversations to the ThinkSpace inbox — so what you reach with AI doesn't scroll away in a chat log, and ends up as cards you arrange with your own hands.
ThinkSpace's philosophy: AI helps gather and diverge; you build the map, because only what you build yourself stays in your head. Accordingly, this server never creates cards directly — it only delivers material to the inbox. Turning material into cards is yours.
Remote server (recommended):
https://mcp.thinkspace-app.com/mcp— works from claude.ai, ChatGPT, Claude Code, and any MCP client that supports OAuth. Notes arrive on every device where you're signed in to ThinkSpace.Local server (legacy): a stdio bridge for Claude Code on the same Mac as the app.
Remote server
Connect
Client | How |
claude.ai (web / desktop / mobile) | Settings → Connectors → Add custom connector → URL |
ChatGPT | Settings → Connectors (developer mode) → Create → MCP server URL |
Claude Code |
|
The client opens ThinkSpace's connection page. Sign in with your ThinkSpace email and password, or — if you use Sign in with Apple — with a 6-digit code from the app: Inbox → link icon (top right) → “Get a connection code” (valid for 10 minutes).
You can see and revoke connections in the same screen in the app. A revoked connection gets a 401 on its next call and the client asks you to connect again.
Use
「いまの結論、受信箱に送って」 "Send this to my ThinkSpace inbox."
The client calls send_to_inbox with the full text of the message and a rough label.
Open the inbox in ThinkSpace (iPhone / iPad / Mac) and decide what becomes a card.
Tool
send_to_inbox
input | description |
| Note body — the verbatim full text of one chat message |
| Label draft, ideally ≤20 characters (you'll rewrite it by hand) |
| Origin identifier, defaults to |
Annotations: readOnlyHint: false, destructiveHint: false, idempotentHint: false.
The server only writes to the inbox; it cannot read your inbox or canvases.
Limits: 60 notes per minute per user; bodies over 30,000 characters are cut at that point and flagged as truncated.
How it works
One Cloudflare Worker serves both the OAuth 2.1 authorization server and the MCP endpoint (Streamable HTTP, stateless). Discovery via RFC 9728 / RFC 8414, dynamic client registration (RFC 7591) and client ID metadata documents, PKCE S256, refresh-token rotation.
The authorization page is ThinkSpace's own. Passwords are verified against ThinkSpace's auth service and never stored or logged. App codes are one-time and expire in 10 minutes.
Each connection is recorded and can be revoked from the app. Tokens carry only the user id and connection id.
Notes are written to the ThinkSpace backend (Supabase) as inbox items and delivered to the app by its normal sync.
Docs for end users: https://support.thinkspace.nextbuild.jp/en/ai-inbox/ Privacy policy: https://thinkspace-public.s3.ap-northeast-1.amazonaws.com/privacy-policy-en-v2.html
Develop
cd remote
npm install
cp .dev.vars.example .dev.vars # SUPABASE_URL / SUPABASE_ANON_KEY / SUPABASE_SERVICE_ROLE_KEY
npx wrangler dev # http://localhost:8787/mcp
./node_modules/.bin/tsc --noEmit
npx wrangler deploySecrets in production are set with wrangler secret put (see remote/wrangler.jsonc).
The service role key lives only in Worker secrets and .dev.vars (gitignored).
Related MCP server: MoonLink
Local server (legacy, macOS only)
A stdio server that hands notes to the ThinkSpace app on the same Mac via the
thinkspace:// URL scheme; the app's own sync then delivers them to your iPad / iPhone.
No account or token is needed, but it only works with Claude Code on that Mac.
claude mcp add thinkspace -- npx -y thinkspace-mcp
# or from a local checkout
git clone https://github.com/naoyax628X/thinkspace-mcp.git
cd thinkspace-mcp && npm install
claude mcp add thinkspace -- node /path/to/thinkspace-mcp/index.jsThe npm package is thinkspace-mcp, published
by the same author as this repository; it contains only index.js (the local bridge).
Requires Node.js 18+ and the ThinkSpace Mac app. The tool is the same send_to_inbox;
source defaults to claude-code, and bodies beyond URL-scheme limits are delivered via
the clipboard channel (source becomes clipboard). Note that the clipboard channel
overwrites whatever is on your clipboard at that moment.
License
MIT
Available Tools
1 toolsend_to_inboxAInspect
Send a note to the ThinkSpace app inbox on this Mac. Use when the user asks to send something to their inbox/ThinkSpace (e.g. 「受信箱に送って」, "send this to ThinkSpace"). Set text to the VERBATIM full text of one chat message (usually one assistant response), unmodified — no summarizing, no rewriting, no trimming. Never invent content. Long bodies are fine (the clipboard channel handles them automatically). title is a label draft of 20 characters or less; the user will rewrite it by hand, so treat it as a rough handle, not a finished title. For multiple notes, call this tool once per note (the app batches notifications).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Note body: the verbatim full text of one chat message, unmodified. | |
| title | No | Label draft, ideally ≤20 characters. | |
| source | No | Origin identifier. Defaults to claude-code. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the verbatim-only contract, that long bodies are handled by a clipboard channel, and that notifications are batched by the app. It omits failure modes and platform prerequisites (e.g. app running, automation permission), which keeps it from a 5.
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 core action is front-loaded in the first sentence, followed by trigger conditions, then per-parameter constraints. Every sentence contributes a distinct rule; the repeated 'no summarizing, no rewriting, no trimming' is deliberate emphasis on the most common failure mode rather than 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?
For a 3-parameter write tool with no annotations and no output schema, the description supplies the behavioral contract, size expectations, and batching semantics. It does not address what happens on failure or whether the ThinkSpace app must be running, which is a modest 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 100%, so the baseline is 3, but the description adds real meaning: `text` must be the verbatim full text of exactly one chat message, and `title` should be ~20 characters versus the schema's hard max of 40, clarifying it is a rough handle the user will rewrite. Only `source` is left to the schema alone.
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 destination: 'Send a note to the ThinkSpace app inbox on this Mac.' The resource (note in the ThinkSpace inbox) and platform scope (this Mac) are unambiguous, so an agent knows exactly what operation is being performed.
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?
Explicitly names the trigger conditions with both English and Japanese example utterances ('send this to ThinkSpace', 「受信箱に送って」), and gives the multi-note routing rule: 'For multiple notes, call this tool once per note.' It also states a hard constraint ('Never invent content'), leaving little to inference.
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.
1 tool update
v0.1.0- First observed
send_to_inbox
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusing it with another. Its purpose (sending a note to the ThinkSpace inbox) is stated unambiguously.
The single name `send_to_inbox` follows a clear verb_destination snake_case pattern. With only one tool there are no inconsistencies to evaluate, and the name is self-descriptive.
A one-tool server is borderline thin, though it may reflect a deliberately narrow scoped integration (one-way note delivery). Whether this is appropriate depends on whether the server is intended as a minimal one-way bridge or a fuller ThinkSpace client.
The surface covers only an outbound send operation: no way to list, read, update, or delete inbox notes. If the domain is strictly one-way note delivery this is complete, but agents cannot verify delivery or manage notes afterward, leaving notable gaps.
Maintenance
Related MCP Connectors
A growing notebook shared by every AI you use. Save in conversation, recall from any connected AI.
Connect inboxes to your AI, with built-in progress and optional owner-confirmed outgoing email.
The first inbox built for you and AI: mail, newsletters, notes, and crosswalks agents share.
Inbox for AI agents: one address per agent to message, share files and pay other agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to save and recall information from files or free-form notes using natural language, acting as a long-term memory system.94 PyPIMIT
- FlicenseNot gradedqualityCmaintenanceEnables AI assistants to capture bookmarks, sticky notes, todos, notes, and web archives, and to search and organize personal knowledge and memory across cloud-synced clients.-
- FlicenseNot gradedqualityAmaintenanceEnables AI assistants to exchange persistent messages across platforms and sessions using natural-language commands such as registering instances, sending messages, and checking inboxes.-
- FlicenseNot gradedqualityAmaintenanceEnables different AI assistants to register identities, send persistent messages, and check inboxes across platforms and sessions using natural language commands.-