Click on "Install 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., "@DriftOS MCP Server route this message to the appropriate branch: 'Can you summarize our discussion about the project timeline?'"
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 server for semantic conversation routing with DriftOS.
An MCP (Model Context Protocol) server that lets any MCP-compatible client (Claude Desktop, Cursor, etc.) use DriftOS for intelligent conversation routing.
Instead of dumping entire conversation histories into LLM context, DriftOS:
Branches when new topics appear
Stays when the topic continues
Routes back when you return to a previous topic
Related MCP server: MCP Server + Document Memory System
This MCP server requires a running DriftOS Core backend.
DriftOS Core is the semantic conversation routing engine that:
Analyzes messages to detect topic shifts and returns
Maintains a graph of conversation branches
Extracts and tracks facts across topics
Assembles relevant context for LLM calls
See the driftos-core repository for setup instructions.
Tool | Description |
| Route a message to the appropriate branch |
| Get assembled context for LLM calls |
| List all branches in a conversation |
| Get details about a specific branch |
Node.js 18+
A running DriftOS backend (default: http://localhost:3000)
npm install
npm run buildSet the DriftOS API URL:
export DRIFTOS_API_URL=http://localhost:3000stdio mode (for Claude Desktop, etc.):
npm startHTTP mode (for remote access):
TRANSPORT=http npm startAdd to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"driftos": {
"command": "node",
"args": ["/path/to/driftos-mcp-server/dist/index.js"],
"env": {
"DRIFTOS_API_URL": "http://localhost:3000"
}
}
}
}MIT
Build a ready-to-use prompt for LLM calls with context and facts.
Args:
branch_id (string): The branch ID to build prompt for
system_prompt (string, optional): Custom system prompt prefix
Returns: { "system": string, // Full system prompt with topic and facts "messages": [{ "role": string, "content": string }] // Conversation messages }
Use this to get a complete prompt ready for OpenAI/Anthropic/etc API calls.
| Name | Required | Description | Default |
|---|---|---|---|
| branch_id | Yes | Branch ID to build prompt for | |
| system_prompt | No | Custom system prompt prefix |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds useful context about what the tool builds (prompts with context and facts) and the intended use (for LLM API calls), but doesn't provide additional behavioral details like rate limits, authentication needs, or performance characteristics beyond what annotations cover.
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 description is well-structured with clear sections (purpose, args, returns, usage) and appropriately sized. Every sentence adds value, though the Args section could be more concise since it largely repeats schema information. The front-loaded purpose statement is effective.
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?
Given the tool's moderate complexity, rich annotations, and 100% schema coverage, the description provides adequate context. It explains what the tool does, shows the return structure (though no formal output schema exists), and indicates usage context. However, it doesn't fully explain how the prompt is constructed from 'context and facts' or clarify the relationship with sibling tools that might provide those inputs.
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?
With 100% schema description coverage, the input schema already fully documents both parameters. The description's Args section repeats the parameter names but doesn't add meaningful semantic context beyond what's in the schema. The baseline score of 3 is appropriate when the schema carries the full parameter documentation burden.
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 clearly states the tool's purpose with specific verbs ('build a ready-to-use prompt for LLM calls') and resources ('with context and facts'). It distinguishes from siblings like driftos_get_context or driftos_get_facts by focusing on prompt construction rather than raw data retrieval.
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 description provides clear context for when to use this tool ('to get a complete prompt ready for OpenAI/Anthropic/etc API calls'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The context is helpful but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger fact extraction for a branch. Use when you want to explicitly extract facts from the current conversation state.
Args:
branch_id (string): The branch ID to extract facts from
Returns: { "facts": [{ "key": string, "value": string }] }
| Name | Required | Description | Default |
|---|---|---|---|
| branch_id | Yes | Branch ID to extract facts from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context beyond annotations: it implies this is an explicit trigger for extraction, suggesting it might be state-changing or processing-intensive. However, annotations already cover key traits (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description doesn't add details like rate limits, auth needs, or what 'trigger' entails operationally, leaving room for improvement.
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 description is appropriately sized and front-loaded: the first sentence states the purpose and usage, followed by structured Args and Returns sections. Every sentence earns its place, but the Returns section could be integrated more seamlessly. It's efficient but not perfectly polished.
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?
Given the tool's moderate complexity (1 parameter, no output schema, annotations provided), the description is fairly complete. It covers purpose, usage, parameters, and return structure. However, it lacks details on what 'facts' entail (e.g., types, format) and doesn't explain the extraction process or potential side effects, which could be useful for an agent.
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 the parameter 'branch_id' fully documented in the schema as 'Branch ID to extract facts from'. The description repeats this in the Args section but adds no additional meaning (e.g., format examples, sourcing instructions, or constraints). With high schema coverage, the baseline is 3, and the description doesn't exceed this by providing extra semantic value.
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 clearly states the tool's purpose: 'Trigger fact extraction for a branch.' It specifies the verb ('extract facts') and resource ('branch'), distinguishing it from siblings like driftos_get_facts (which likely retrieves existing facts) and driftos_get_context (which gets broader context). However, it doesn't explicitly contrast with all siblings, such as driftos_build_prompt or driftos_route_message.
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 description provides clear usage context: 'Use when you want to explicitly extract facts from the current conversation state.' This gives a specific scenario for when to invoke the tool. However, it doesn't explicitly state when not to use it or name alternatives (e.g., driftos_get_facts for retrieving already-extracted facts), which would be needed for a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get assembled context for a conversation branch, including messages and facts from related branches.
This is what you pass to an LLM instead of the entire conversation history. Returns only the relevant messages from the current branch plus accumulated facts.
Args:
branch_id (string): The branch ID to get context for (returned from route_message)
Returns: { "branchId": string, "branchTopic": string, "messages": [ { "role": "user" | "assistant", "content": string } ], "allFacts": [ { "branchTopic": string, "isCurrent": boolean, "facts": [{ "key": string, "value": string, "confidence": number }] } ] }
Use this to build focused LLM context windows instead of dumping entire conversation history.
| Name | Required | Description | Default |
|---|---|---|---|
| branch_id | Yes | Branch ID to get context for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, and idempotent behavior, but the description adds valuable context beyond this: it explains that the tool returns 'only the relevant messages' (implying filtering), specifies the output structure in detail, and clarifies the purpose ('build focused LLM context windows'). No contradictions with annotations exist.
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 description is well-structured and front-loaded with the core purpose, followed by details on arguments, returns, and usage. It avoids redundancy, though the detailed return structure could be considered slightly verbose. Most sentences earn their place by adding clarity or guidance.
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?
Given the tool's complexity (assembling context from multiple branches), rich annotations, and detailed return description in the text, the description is complete enough. It covers purpose, usage, parameters, and output structure, compensating for the lack of an output schema. No significant gaps remain for effective tool selection and invocation.
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 the parameter 'branch_id' fully documented in the schema. The description adds minimal value beyond the schema by noting it's 'returned from route_message', but doesn't provide additional semantics like format examples or constraints. Baseline 3 is appropriate given high schema coverage.
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 clearly states the specific action ('Get assembled context') and resource ('conversation branch'), distinguishing it from siblings by focusing on context assembly rather than prompt building, fact extraction, or branch listing. It explicitly mentions including 'messages and facts from related branches' which differentiates its scope.
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 description provides explicit guidance on when to use this tool ('This is what you pass to an LLM instead of the entire conversation history') and names a specific alternative approach ('dumping entire conversation history'). It also references a sibling tool ('route_message') as the source for branch_id, though it doesn't explicitly contrast with other siblings like 'driftos_get_facts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get extracted facts from a specific branch.
Args:
branch_id (string): The branch ID to get facts for
Returns: [{ "key": string, "value": string, "confidence": number }]
| Name | Required | Description | Default |
|---|---|---|---|
| branch_id | Yes | Branch ID to get facts for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, non-destructive, idempotent, and closed-world, covering key behavioral traits. The description adds minimal context beyond this, specifying it retrieves 'extracted facts' and the return format, but doesn't mention aspects like rate limits, authentication needs, or what 'extracted facts' entail. With annotations providing safety profile, a baseline 3 is appropriate as the description adds some value but not rich behavioral details.
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 description is appropriately sized and front-loaded, with the core purpose stated first. The Args and Returns sections are structured but could be more concise; for example, the return format is detailed but might be redundant if an output schema existed. Overall, it's efficient with minimal 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?
Given the tool's low complexity (1 parameter, no output schema), annotations provide rich safety context, and the description covers the purpose and return format adequately. It doesn't explain sibling differentiation or usage guidelines, but for a simple read operation, it's mostly complete. The lack of output schema means the return description adds necessary value.
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 the parameter 'branch_id' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples, constraints, or context about branch IDs). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
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 clearly states the action ('Get extracted facts') and target resource ('from a specific branch'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'driftos_get_context' or 'driftos_extract_facts', which might also involve facts or branch data, so it doesn't achieve full sibling differentiation.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'driftos_get_context' (which might provide broader context) or 'driftos_extract_facts' (which might create facts), leaving the agent without explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all branches in a conversation with their topics and message counts.
Use this to understand the structure of a conversation and see what topics have been discussed.
Args:
conversation_id (string): Unique identifier for the conversation
Returns: [ { "id": string, "topic": string, "messageCount": number, "isActive": boolean } ]
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | Unique identifier for the conversation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide comprehensive behavioral hints (read-only, non-destructive, idempotent, closed-world). The description adds useful context about the tool's purpose in analyzing conversation structure, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or pagination behavior beyond what annotations cover.
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 description is well-structured with purpose first, usage guidance second, and parameter/return details last. However, the Args section duplicates schema information unnecessarily, and the Returns section could be more concise given there's no output schema.
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 read-only list operation with comprehensive annotations and a simple single parameter, the description provides adequate context. The return format is documented, and the purpose is clear. However, without an output schema, the description could benefit from more detail about the structure of returned branches.
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 the parameter clearly documented. The description repeats the same parameter information in the Args section without adding additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
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 clearly states the verb 'List' and resource 'all branches in a conversation' with specific details about what information is returned ('topics and message counts'). It distinguishes from siblings by focusing on conversation structure analysis rather than prompt building, fact extraction, or message routing.
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 description provides clear context for when to use this tool ('to understand the structure of a conversation and see what topics have been discussed'), which helps differentiate it from sibling tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Route a message to the appropriate conversation branch using semantic drift detection.
Returns one of three actions:
BRANCH: New topic detected, creates a new branch
STAY: Message continues the current topic
ROUTE: Returns to a previously discussed topic
Args:
conversation_id (string): Unique identifier for the conversation
content (string): The message content to route
role ('user' | 'assistant'): Who sent the message (default: 'user')
Returns: { "action": "BRANCH" | "STAY" | "ROUTE", "branchId": string, "branchTopic": string, "confidence": number, "isNewBranch": boolean }
Example:
"I want to buy a house in London" -> BRANCH (new topic)
"What areas have good schools?" -> STAY (same topic)
"Back to houses - what about mortgage rates?" -> ROUTE (returns to previous branch)
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | Unique identifier for the conversation | |
| content | Yes | The message content to route | |
| role | No | Who sent the message | user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-destructive, non-idempotent tool, but the description adds valuable behavioral context beyond that. It explains the three possible actions (BRANCH, STAY, ROUTE) and what they mean in practice (e.g., 'creates a new branch', 'continues the current topic'), which is not covered by annotations. However, it does not mention potential side effects like rate limits or authentication needs.
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 description is well-structured and front-loaded with the core purpose, followed by clear sections for returns, args, and examples. Every sentence adds value—none are redundant or wasteful—making it efficient and easy to parse for an AI agent.
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?
Given the tool's complexity (semantic routing with multiple outcomes) and lack of an output schema, the description provides comprehensive context. It fully explains the return structure, actions, and includes practical examples, compensating for the missing output schema and ensuring the agent understands how to interpret results.
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 the schema already documents all parameters thoroughly. The description repeats parameter names and basic meanings in the 'Args' section but does not add significant semantic details beyond what the schema provides, such as explaining how 'role' affects routing decisions. This meets the baseline of 3 for high schema coverage.
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 clearly states the specific action ('Route a message') and mechanism ('using semantic drift detection'), distinguishing it from sibling tools like 'driftos_list_branches' or 'driftos_extract_facts'. It explicitly defines the three possible routing outcomes (BRANCH, STAY, ROUTE), making the purpose highly specific and differentiated.
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 description provides clear context for when to use this tool ('Route a message to the appropriate conversation branch') and includes examples that illustrate different scenarios (new topic, same topic, return to previous topic). However, it does not explicitly state when NOT to use it or name alternatives among sibling tools, such as when to use 'driftos_get_context' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: route_message handles message routing, list_branches lists branches, get_context assembles context, build_prompt constructs prompts, get_facts retrieves facts, and extract_facts triggers fact extraction. The descriptions clearly differentiate their functions, making tool selection unambiguous.
All tools follow a consistent verb_noun naming pattern with the 'driftos_' prefix (e.g., driftos_route_message, driftos_list_branches). The structure is uniform throughout, using snake_case consistently without any deviations or mixed conventions.
With 6 tools, this server is well-scoped for managing conversation branches, context, and facts in a drift detection system. Each tool serves a specific, necessary function (routing, listing, context assembly, prompt building, fact retrieval, and fact extraction), and none feel redundant or missing for the domain.
The tool set provides complete coverage for the conversation drift management domain: routing messages, listing branches, getting context, building prompts, and handling facts (both retrieval and extraction). There are no obvious gaps; agents can perform all core operations from routing to LLM integration without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
Calibrated AI skill routing via orbital mechanics — picks the right expertise for every query.
Shared semantic graph for AI reviews, classification and structured memory across AI assistants.
Memory for deep conversational context across any platform
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DriftOS/driftos-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
