Skip to main content
Glama

Start Context Engine

start_context_engine

Initialize the context engine to access current library documentation and code examples for AI coding assistance.

Instructions

Starts the context engine and returns a confirmation message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectRootYesThe project root directory

Implementation Reference

  • Core implementation of the startContextEngine function, which handles local documentation setup and remote API call to start the context engine.
    export async function startContextEngine(
      projectRoot: string,
      clientIp?: string,
      apiKey?: string,
      serverUrl?: string
    ): Promise<string> {
      if (!projectRoot) {
        throw new Error("Project root directory is required for context engine initialization");
      }
    
      let apiResponse = "";
      let documentationStatus = "";
    
      try {
        // Step 1: Setup local documentation structure first
        logger.info("Setting up local documentation structure");
        const setupResult = await setupDocumentationStructure(projectRoot);
    
        if (setupResult.success) {
          documentationStatus = `\n\nšŸ“ Local Documentation Structure: ${setupResult.message}`;
          logger.info("Local documentation structure setup completed", {
            status: setupResult.status as unknown as Record<string, unknown>,
          });
        } else {
          logger.warn("Local documentation structure setup failed", {
            status: setupResult.status as unknown as Record<string, unknown>,
          });
          // Don't proceed with API call if local setup fails
          return `āŒ Failed to setup local documentation structure: ${setupResult.message}`;
        }
      } catch (error) {
        logger.error("Local documentation structure setup failed", {
          error: error instanceof Error ? error.message : String(error),
        });
        // Don't proceed with API call if local setup fails
        return `āŒ Failed to setup local documentation structure: ${error instanceof Error ? error.message : String(error)}`;
      }
    
      try {
        // Step 2: Start the context engine via API (only if local setup succeeded)
        logger.info("Starting ContextEngine via API");
        const url = buildApiUrl("start-context-engine", {}, serverUrl);
        const headers = generateHeaders(clientIp, apiKey, { "X-ContextEngine-Source": "mcp-server" });
    
        const response = await makeApiRequest(url, headers, "start context engine");
        const text = await response.text();
    
        if (!text || text === "No content available") {
          apiResponse = "Context engine start request sent but no confirmation available.";
        } else {
          apiResponse = text;
        }
    
        logger.info("ContextEngine API call successful");
      } catch (error) {
        logger.error("ContextEngine API call failed", {
          error: error instanceof Error ? error.message : String(error),
        });
    
        apiResponse = `āš ļø  ContextEngine API call failed: ${error instanceof Error ? error.message : String(error)}`;
      }
      
      // Return combined response
      return `${apiResponse}${documentationStatus}`;
    }
  • src/index.ts:77-107 (registration)
    MCP tool registration for 'start_context_engine', including input schema, description, and handler that delegates to the core startContextEngine function.
    server.registerTool(
      "start_context_engine",
      {
        title: "Start Context Engine",
        description: "Starts the context engine and returns a confirmation message.",
        inputSchema: {
          projectRoot: z.string().describe("The project root directory"),
        },
      },
      async (args) => {
        // Validate API key based on environment
        validateApiKey(apiKey, finalServerUrl);
    
        const startContextEngineResponse = await startContextEngine(
          args.projectRoot,
          clientIp,
          apiKey,
          finalServerUrl
        );
    
        return {
          content: [
            {
              type: "text",
              text: startContextEngineResponse,
            },
          ],
        };
      }
    );
  • Input schema definition for the tool using Zod, requiring projectRoot string.
    {
      title: "Start Context Engine",
      description: "Starts the context engine and returns a confirmation message.",
      inputSchema: {
        projectRoot: z.string().describe("The project root directory"),
      },
    },
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions starting the engine and returning a confirmation, but lacks details on side effects (e.g., does it initialize resources, affect system state?), performance implications, or error handling. This is inadequate for a tool that likely performs a system operation.

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 description is a single, clear sentence with no wasted words. It's front-loaded with the core action and outcome, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is insufficient for a tool that starts an engine. It doesn't explain what the context engine is, what the confirmation message contains, or potential impacts, leaving gaps in understanding the tool's full behavior and use.

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%, so the schema fully documents the single parameter 'projectRoot'. The description adds no additional meaning about parameters beyond what the schema provides, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Starts') and resource ('context engine'), and specifies the outcome ('returns a confirmation message'). It's specific enough to understand what the tool does, though it doesn't differentiate from siblings since none exist.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool, such as prerequisites, typical scenarios, or conditions for invocation. The description only states what it does, not when it should be used.

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/livelifelively/context-engine-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server