Skip to main content
Glama
DriftOS

DriftOS MCP Server

Official
by DriftOS

Get Conversation Context

driftos_get_context
Read-onlyIdempotent

Retrieve focused conversation context for LLMs by extracting relevant messages and accumulated facts from specific branches, reducing history overload.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
branch_idYesBranch ID to get context for

Implementation Reference

  • Executes the tool logic: calls driftClient.getContext(branch_id), stringifies the result as JSON text response, or returns error if failed.
    async (params) => {
      try {
        const result = await driftClient.getContext(params.branch_id);
    
        return {
          content: [
            {
              type: 'text' as const,
              text: JSON.stringify(result, null, 2),
            },
          ],
        };
      } catch (error) {
        const message = error instanceof Error ? error.message : 'Unknown error';
        return {
          content: [
            {
              type: 'text' as const,
              text: `Error getting context: ${message}`,
            },
          ],
          isError: true,
        };
      }
    }
  • Zod input schema validating the branch_id parameter.
    inputSchema: z.object({
      branch_id: z.string().min(1).describe('Branch ID to get context for'),
    }).strict(),
  • Direct registration of the 'driftos_get_context' tool on the MCP server, including title, description, input schema, annotations, and inline handler function.
      server.registerTool(
        'driftos_get_context',
        {
          title: 'Get Conversation Context',
          description: `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.`,
          inputSchema: z.object({
            branch_id: z.string().min(1).describe('Branch ID to get context for'),
          }).strict(),
          annotations: {
            readOnlyHint: true,
            destructiveHint: false,
            idempotentHint: true,
            openWorldHint: false,
          },
        },
        async (params) => {
          try {
            const result = await driftClient.getContext(params.branch_id);
    
            return {
              content: [
                {
                  type: 'text' as const,
                  text: JSON.stringify(result, null, 2),
                },
              ],
            };
          } catch (error) {
            const message = error instanceof Error ? error.message : 'Unknown error';
            return {
              content: [
                {
                  type: 'text' as const,
                  text: `Error getting context: ${message}`,
                },
              ],
              isError: true,
            };
          }
        }
      );
  • Creation of the driftClient instance used in the tool handler to perform the getContext call.
    export const driftClient = createDriftClient(DRIFTOS_API_URL);
  • src/index.ts:18-18 (registration)
    Top-level call to registerContextTools during MCP server initialization, which includes registration of driftos_get_context.
    registerContextTools(server);
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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