ultrathink-mcp
Ultrathink MCP Server
Save and search your Ultrathink knowledge base from any MCP-compatible client: Claude Desktop, Claude Code, Cursor, Zed and more.
Ultrathink is a second-brain app that captures notes, links, screenshots, AI conversations, PDFs and more into a single AI-searchable knowledge base.
New: the hosted Ultrathink MCP server
Ultrathink now runs its own MCP server online, so there is nothing to install. It has more tools than this package: search, read an entry in full, related entries, recent changes, everything about a person or a topic, lists of your topics and people, and adding and updating entries.
Connect Claude Code with one command, using a device key with API access:
claude mcp add --transport http ultrathink https://us-central1-ultrathink-50f7f.cloudfunctions.net/mcp --header "Authorization: Bearer YOUR_DEVICE_KEY"Any MCP client that supports remote servers over HTTP with a header can use the same address. Setup, tools and troubleshooting are in the MCP server guide.
The hosted server is the recommended way to connect. This package keeps working, with the two tools below, for clients that only run local servers.
Related MCP server: open-brain-mcp
This package
It gives your AI assistant two tools:
ultrathink_save: store a note, link, idea or snippet in your knowledge baseultrathink_search: natural-language search across everything you've captured
Install
npm install -g ultrathink-mcpOr use directly with npx ultrathink-mcp (no install needed).
Configuration
You need an Ultrathink device key. Get one at tryultrathink.com.
Set as environment variables:
export ULTRATHINK_DEVICE_KEY="your-device-key-here"Optional:
export ULTRATHINK_API_BASE="https://us-central1-ultrathink-50f7f.cloudfunctions.net" # default
export ULTRATHINK_SOURCE="claude-code" # tag entries with a source labelUse with Claude Code
Add to your ~/.claude.json mcpServers:
{
"mcpServers": {
"ultrathink": {
"command": "npx",
"args": ["-y", "ultrathink-mcp"],
"env": {
"ULTRATHINK_DEVICE_KEY": "your-device-key-here"
}
}
}
}Use with Claude Desktop
Add to your claude_desktop_config.json:
{
"mcpServers": {
"ultrathink": {
"command": "npx",
"args": ["-y", "ultrathink-mcp"],
"env": {
"ULTRATHINK_DEVICE_KEY": "your-device-key-here"
}
}
}
}Tools
ultrathink_save
Save an entry to your Ultrathink knowledge base.
Inputs:
title(required): title of the entrynotes: main content for most entriescontent: full content for longer entriestype: one ofnote,link,idea,snippet,para,chatgpt,claude,perplexity,notion,long-note,profile. Default:noteurl: required whentypeislinkvisibility:private(default) ororg
ultrathink_search
Natural-language search across your Ultrathink knowledge base. Returns an AI-generated answer based on stored entries.
Inputs:
query(required): natural-language search queryentityFilter: optional, one ofproject,task,knowledge
Licence
MIT
Available Tools
2 toolsultrathink_saveB
Save an entry to Ultrathink knowledge base. Use this to store notes, ideas, links, snippets, and other knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL (required for link type) | |
| type | No | Type of entry. Default: note | |
| notes | No | Notes or description (main content for most entries) | |
| title | Yes | Title of the entry | |
| content | No | Full content (for longer entries) | |
| visibility | No | Visibility: private (default) or org (shared with organization) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and only conveys that this is a write. It says nothing about what is returned (an ID?), whether duplicate titles overwrite or create a second entry, permission or org-sharing behavior behind visibility, or what happens if type=link without a url.
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?
Two short sentences with the action leading and the usage examples second – appropriately sized and front-loaded. The second sentence borders on generic ('other knowledge') but does not waste much space.
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?
The rich input schema compensates for much of the missing detail, and no output schema exists so return values needn't be spelled out. However, for a 6-parameter mutation tool with zero annotations, the description leaves an agent without the create-vs-update semantics or failure behavior it would need to call this confidently.
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 description coverage is 100%, so both enum values and each field's meaning (url required for link, visibility private/org, type default note) are already documented. The description adds nothing beyond restating a subset of the content types, so the baseline 3 applies.
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+resource ('Save an entry to Ultrathink knowledge base') and illustrates the kinds of content it accepts. It separates itself from the only sibling, ultrathink_search, by implication (save vs. search), though it never names the alternative.
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?
The second sentence gives examples of when to reach for it (notes, ideas, links, snippets), which implies the trigger condition. There is no explicit when-not guidance, no mention of updating vs. creating, and no reference to ultrathink_search as the retrieval counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ultrathink_searchA
Search the Ultrathink knowledge base using natural language. Returns an AI-generated answer based on stored entries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query | |
| entityFilter | No | Optional filter by entity type |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the important trait that results are AI-generated answers derived from stored entries rather than literal matches. It says nothing about read-only safety, latency/cost of generation, empty-result behavior, or whether source entries are cited.
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?
Two sentences, zero waste, with the core action front-loaded and the return behavior immediately after. Nothing in it is redundant.
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?
There is no output schema, so the description must characterize the return value, and it does so only in one broad clause. For a simple two-parameter read tool this is close, but the answer shape (citations, multiple entries, result limits) remains undefined.
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 description coverage is 100%, with both parameters and the enum values documented inline, so the baseline is 3. The description adds no meaning beyond the schema for query or entityFilter, such as expected phrasing or what happens when the filter is omitted.
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?
The description names a specific verb (Search) and resource (the Ultrathink knowledge base) and clarifies that the output is a synthesized answer rather than raw records. That distinguishes it well from the only sibling, ultrathink_save, though the contrast is never stated explicitly.
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?
Usage is only implied: an agent can infer this is the retrieval path versus ultrathink_save for storage, and that entityFilter narrows scope. There is no explicit when-to-use, when-not-to-use, or guidance on choosing between filtered and unfiltered searches.
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.
2 tool updates
v1.0.1- First observed
ultrathink_save - First observed
ultrathink_search
TDQS
Scored across 2 tools
The two tools perform clearly opposite, non-overlapping operations: write (save) and read (search). An agent can instantly choose between storing knowledge and retrieving it, with no ambiguity.
Both tools follow an identical pattern: the `ultrathink_` namespace prefix plus a concise verb (save, search). Fully predictable and consistent.
Two tools is on the thin side for a knowledge base server; a minimal capture-and-retrieve surface works, but there is little else an agent can do. It sits at the borderline of under-scoped.
Core store-and-query flow is covered, but obvious knowledge-management operations are absent: no update, delete, list/recent entries, or get-by-id. Agents cannot correct or manage stored entries, only add and search.
Maintenance
Related MCP Connectors
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP Memory Server for Claude Code that provides persistent context across sessions using semantic search (RAG).Apache 2.0
- AlicenseNot gradedqualityDmaintenanceAn MCP server for storing and retrieving thoughts, notes, and ideas with semantic vector search, enabling integration with Claude Desktop and other MCP clients.MIT
- AlicenseNot gradedqualityDmaintenancePersistent memory MCP server for Claude Code. Store, search, and retrieve memories across sessions using hybrid vector + keyword search powered by SQLite, FTS5, and sqlite-vec.8 npm1MIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that enables Claude Desktop or Claude Code to ingest and search local documents using vector embeddings, returning relevant chunks as tool results for the model to reason over.-