1. Initializing MCP#

First, we bootstrap a project using the official MCP starter. Navigate to a neutral directory (not inside A or B) and run:

1
npx @modelcontextprotocol/create-server my-docs-bridge
2
cd my-docs-bridge
3
npm install

2. Defining Resources and Tools#

In src/index.ts, define how the agent “sees” Project B. We have two 2 options:

1. Resources: Best for static data. We can expose specific files in Project B as URI-based resources (e.g., docs://project-b/deploy.md).
2. Tools: Best for dynamic actions. We can create a tool called get_deployment_docs that takes a project name as an argument and returns the relevant file content from Project B.

3. Implementing the Logic#

Here is a simplified logic structure for our server using the TypeScript SDK. This example uses a tool-based approach to fetch documentation:

1
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
2
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
3
import {
4
  CallToolRequestSchema,
5
  ListToolsRequestSchema,
6
} from "@modelcontextprotocol/sdk/types.js";
7
import fs from "fs/promises";
8
import path from "path";
9

10
const server = new Server({
11
  name: "project-b-bridge",
12
  version: "1.0.0",
13
}, {
14
  capabilities: {
15
    tools: {},
16
  },
17
});
18

19
// 1. List the tools available to the agent
20
server.setRequestHandler(ListToolsRequestSchema, async () => ({
21
  tools: [{
22
    name: "read_project_b_docs",
23
    description: "Read deployment documentation for a specific project from Project B",
24
    inputSchema: {
25
      type: "object",
26
      properties: {
27
        filename: { type: "string", description: "e.g., project-a-deploy.md" }
28
      },
29
      required: ["filename"]
30
    }
31
  }]
32
}));
33

34
// 2. Handle the tool execution
35
server.setRequestHandler(CallToolRequestSchema, async (request) => {
36
  if (request.params.name === "read_project_b_docs") {
37
    const docPath = path.join("/absolute/path/to/Project-B/docs", request.params.arguments.filename);
38
    try {
39
      const content = await fs.readFile(docPath, "utf-8");
40
      return { content: [{ type: "text", text: content }] };
41
    } catch (error) {
42
      return { content: [{ type: "text", text: `Error reading docs: ${error.message}` }], isError: true };
43
    }
44
  }
45
  throw new Error("Tool not found");
46
});
47

48
const transport = new StdioServerTransport();
49
await server.connect(transport);

4. Connecting to Agent (the “Client”)#

The MCP server runs as a separate process. We to tell our AI client how to start it. Take Gemini CLI as an example, Gemini CLI looks for MCP server configurations in a specific JSON file. This is usually located at ~/.gemini/settings.json

Add the new bridge server to the mcpServers object:

1
{
2
  "mcpServers": {
3
    "docs-bridge": {
4
      "command": "node",
5
      "args": [
6
        "/absolute/path/to/my-docs-bridge/build/index.js"
7
      ],
8
      "env": {
9
        "PROJECT_B_PATH": "/absolute/path/to/Project-B/docs",
10
        "NODE_ENV": "production"
11
      }
12
    }
13
  }
14
}

Key Integration Tips for the CLI

• Use Absolute Paths: The Gemini CLI runs from various working directories. Always use absolute paths for the node executable (if not in global PATH) and the index.js file to avoid “file not found” errors during the handshake.
• Environment Variables: Note the env block above. It is better practice to pass the directory of Project B as an environment variable rather than hardcoding it in TypeScript source. This keeps MCP server generic and reusable.
• Permissions: Ensure the user running the Gemini CLI has read permissions for the Project B directory.

5 - Verification#

To verify the connection, restart Gemini CLI session and run a diagnostic command if available, or simply ask:

“List the available tools from my MCP servers.”

If configured correctly, we should see read_project_b_docs appear in the list of capabilities. This confirms the CLI has successfully “attached” to our local documentation bridge.

6 - Context File#

Even with an MCP server running, an AI agent needs a “reason” to use it. Without a hint in Project A, the agent might spend time looking for a Dockerfile or a docker-compose.yml within Project A’s directory in case of deploying A. When it fails to find them, it might try to hallucinate a deployment strategy based on general knowledge instead of using our specific centralized docs.

It is, therefore, highly recommended to keep a note in, in case of Gemini, GEMINI.md context file and frame it as an instruction pointer for the agent like this:

1
Deployment
2
----------
3

4
Deployment logic for this project is centralized in Project B. To understand how to deploy Project A:
5

6
1. Use the `read_project_b_docs` tool.
7
2. Request the file: `project-a-deployment.md`.
8
3. Follow the instructions regarding the Docker configuration defined there.

Result#

When we start a session in Project A:

1. The agent reads GEMINI.md.
2. It identifies that deployment is “external.”
3. It sees it has a tool (read_project_b_docs) that matches the instruction.
4. It proactively fetches the documentation from Project B before we even ask a specific deployment question.

This creates a seamless “web” of knowledge across our local repositories. We keep Project A clean of duplicate docs, but we give the agent the “map” it needs to find the truth in Project B.

1. Installing Package#

We can run it directly using npx (which ensures we always have the latest version) or install it globally:

1
npm install -g @modelcontextprotocol/server-filesystem

Configuring Gemini CLI#

Update settings.json to use the official server. The most important part here is passing the centralized project root as an argument:

1
{
2
  "mcpServers": {
3
    "filesystem": {
4
      "command": "npx",
5
      "args": [
6
        "-y",
7
        "@modelcontextprotocol/server-filesystem",
8
        "/path/to/your/centralized/projects/root",
9
        "/path/to/another/relevant/dir"
10
      ]
11
    }
12
  }
13
}

(To be continued…)