Grok Build · Tool Execution Architecture

Implementation Families, Registry, and Dynamic MCP

xai-grok-tools houses multiple sets of built-in tool implementations alongside runtime MCP tools. ToolBridge connects the registry to the session layer, while SearchTool and UseTool provide the discovery and invocation entry points.

Learning Objective: Given a namespace, identify the corresponding implementation family; explain how tool definitions enter the registry and get executed by ToolBridge; accurately reproduce the real input fields for both MCP meta-tools.
Key Visual · Data Flow from Definition to Execution
Impl. Familygrok_build · codex · opencode Dynamic MCPRuntime Registry ToolRegistryBuilderSelect · Param Renamefinalize(config, context) FinalizedToolsetdefinitions · resourcesdispatch ToolBridgeSession AdapterCall & Result tool definitions exposed to model ToolOutput / prompt_text
Pedagogical diagram: types and methods are from source code; layout is for classroom explanation.
Implementation Families in Source Code
grok_build

Primary product tool family, containing ReadFile, SearchReplace, Bash, Task, and other implementations.

grok_build_concise

Lean tool family; directory contains read_file, search_replace, and bash.

grok_build_hashline

read_file, edit, and grep implementations with hashline semantics.

codex

Contains apply_patch, read_file, list_dir, grep_files, and other compatible implementations.

opencode

Contains read, write, edit, bash, glob, grep, skill, and todowrite.

memory / lsp / skills

Implementation modules split by capability. The namespace enum also includes MCP for runtime external tools.

Two Stable Entry Points for Dynamic MCP

SearchTool

Searches MCP tools in ToolIndex using BM25. Results are grouped by server and return tool descriptions with input_schema.

query: Stringkeyword
limit: Option<u8>default 5

UseTool

Accepts a discovered tool name and invokes MCP via InnerDispatch or a managed gateway. This fixed entry point keeps the model's tool list stable across turns.

tool_name: Stringtypically server__tool
tool_input: Valueconstructed per discovered schema
Real Source Code Evidence
crates/codegen/xai-grok-tools/src/bridge.rs and implementations/use_tool/mod.rs
pub struct ToolBridge {
    registry: Arc<FinalizedToolset>,
    terminal: Option<Arc<dyn TerminalBackend>>,
}

pub async fn register_mcp_tools<T>(
    &self,
    mcp_name: String,
    tool: T,
    input_schema: Option<serde_json::Value>,
) -> Result<(), xai_tool_runtime::ToolError> {
    self.registry.register_tool(mcp_name, tool, input_schema)?;
    Ok(())
}

pub struct UseToolInput {
    pub tool_name: String,
    pub tool_input: serde_json::Value,
}
Source snapshot note: Based on local repository grok-build-main. Key files cross-referenced: xai-grok-tools/src/implementations/mod.rs, types/tool.rs, bridge.rs, registry/types.rs, implementations/search_tool, and implementations/use_tool. Verified 2026-07-17.
Classroom Exercise
03

Trace an External Tool Call

Starting from the model's initial call to search_tool, write down the query field, the schema to read from the response, the two fields then passed to use_tool, and which bridge type ultimately returns the result to the session.

Takeaway: Implementation families handle code organization for multiple tool protocols; the registry manages composition and runtime registration; ToolBridge connects to the session. Dynamic MCP discovers schemas via SearchTool, then dispatches execution via UseTool according to the discovered schema.