DeepWiki and Custom Tools

DeepWiki: A Public Server for Practice

Everything you’ve seen so far remains abstract until you connect a real server. DeepWiki is the ideal candidate for this first test: it exposes a public MCP server at https://mcp.deepwiki.com/mcp, without authentication, that provides access to documentation for any GitHub project.

The configuration takes just a few lines, since the only optional parameter that really matters here is the description.

from xai_sdk.tools import mcp

tools = [
    mcp(
        server_url="https://mcp.deepwiki.com/mcp",
        server_label="deepwiki",
        server_description="Documentation for open-source GitHub projects. Search and view code, READMEs, guides."
    )
]

Once this connection is established, ask Grok questions that actually require reading the repository: “explain how routing works in the facebook/react project,” “what are the configuration options for vercel/next.js?”, or “show me the project structure for langchain-ai/langchain”. The model calls the DeepWiki tools, retrieves documentation and source code, then synthesizes a structured response. Compare this response to what you would get without the MCP server: the difference between what the model knows and what it just read is immediately obvious.

Moving to Your Own Servers

DeepWiki is an excellent training ground, but the real value of MCP appears when the server exposes what no one else can: your data, your processes, your business tools.

Technically, an MCP server is a web application that responds to two types of requests. Discovery first: when Grok connects, it requests the list of available tools with their schemas. Execution next: when the model decides to call a tool, it transmits the tool name and its arguments, then waits for the result. The server must expose an HTTPS endpoint compliant with the MCP protocol, using Streaming HTTP or SSE—the two transports covered at the start of the course.

What makes a custom server interesting isn’t the technique but the choice of tools it publishes. Here are three examples of coherent splitting, where each server covers one domain and only one:

Server "analytics":
  - get_dashboard_metrics: dashboard metrics
  - query_events: query analytic events
  - get_funnel_report: conversion funnel report

Server "content":
  - search_articles: search within the CMS
  - get_article: retrieve a full article
  - list_categories: list content categories

Server "devops":
  - get_deploy_status: status of the last deployment
  - list_alerts: active monitoring alerts
  - get_service_health: health of a specific service

This domain splitting isn’t just for show: it lets you tier authentication and server restrictions per server, rather than applying a single rule to a mixed bag of heterogeneous tools. Once your server is deployed, the connection follows exactly the DeepWiki pattern, augmented with the token and allowlist.

tools = [
    mcp(
        server_url="https://mcp.yourcompany.com/analytics",
        server_label="analytics",
        server_description="Analytics metrics and reports. Dashboards, funnels, events.",
        authorization=f"Bearer {os.getenv('ANALYTICS_TOKEN')}",
        allowed_tool_names=["get_dashboard_metrics", "query_events"]
    )
]

Public and Internal Servers in the Same Session

Configurations become truly interesting when you mix both families, because the model can then correlate a public source with a source only you have.

tools = [
    # Public server for open-source documentation
    mcp(
        server_url="https://mcp.deepwiki.com/mcp",
        server_label="deepwiki",
        server_description="Documentation for open-source GitHub projects"
    ),
    # Internal server for product documentation
    mcp(
        server_url="https://docs.yourcompany.com/mcp",
        server_label="internal-docs",
        server_description="Internal technical documentation, architecture guides, ADRs",
        authorization=f"Bearer {os.getenv('DOCS_TOKEN')}"
    ),
    # Internal server for business data
    mcp(
        server_url="https://api.yourcompany.com/mcp",
        server_label="data",
        server_description="Business data: customers, orders, inventory",
        authorization=f"Bearer {os.getenv('API_TOKEN')}",
        allowed_tool_names=["search_customers", "get_order", "check_inventory"]
    ),
]

Then ask Grok to compare the official React documentation with your internal architecture guide on routing: it queries DeepWiki for the first and your documentation server for the second, then contrasts the two. No model can produce this response from its own knowledge alone, and neither can web search, since half the material exists only at your company.

Notice finally how the three servers are configured differently. The public server has neither token nor allowlist, the internal documentation has a token but remains largely open because it is read-only, and the business data combines token and strict restriction to three operations. Each server carries the level of control its content justifies—that’s exactly the point of separating them.

Key Takeaways

• DeepWiki (https://mcp.deepwiki.com/mcp) is a ready-to-use public MCP server for GitHub documentation
• You can create your own MCP servers to expose tools specific to your business
• A custom MCP server is an HTTPS web application that responds to discovery and execution requests
• Combining public and internal servers yields the most powerful configurations
• Each server maintains its own level of authentication and tool restriction