Skip to main content
Glama

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 https://mcp.thinkspace-app.com/mcp

ChatGPT

Settings → Connectors (developer mode) → Create → MCP server URL https://mcp.thinkspace-app.com/mcp, auth OAuth

Claude Code

claude mcp add --transport http thinkspace https://mcp.thinkspace-app.com/mcp then /mcp to sign in

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

text (required)

Note body — the verbatim full text of one chat message

title (optional)

Label draft, ideally ≤20 characters (you'll rewrite it by hand)

source (optional)

Origin identifier, defaults to mcp

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 deploy

Secrets 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.js

The 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 tool
send_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).

NameRequiredDescriptionDefault
textYesNote body: the verbatim full text of one chat message, unmodified.
titleNoLabel draft, ideally ≤20 characters.
sourceNoOrigin identifier. Defaults to claude-code.

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev0.1.0
    • First observedsend_to_inbox

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness3/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    C
    maintenance
    Enables 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.
    -
  • F
    license
    Not graded
    quality
    A
    maintenance
    Enables AI assistants to exchange persistent messages across platforms and sessions using natural-language commands such as registering instances, sending messages, and checking inboxes.
    -
  • F
    license
    Not graded
    quality
    A
    maintenance
    Enables different AI assistants to register identities, send persistent messages, and check inboxes across platforms and sessions using natural language commands.
    -