MCP Tools

request_contextNew

Submits a task to Driver's context agent and returns a request ID immediately. The agent runs server-side, starting from the codebase atlas and following precomputed relationship and change-impact edges to synthesize a brief for your task. This call does not return the context: retrieve it with poll_context.

Runs typically take one to three minutes. Because submitting is cheap and asynchronous, fire several requests in parallel for distinct questions and poll each in turn.

Parameters

When to use

The entry point before planning, implementing, debugging, or refactoring. Reach for it when you need to understand how something works end to end rather than to look up one fact.

Collect task-specific deep context with Driver MCP tools →

Example prompt

"Get me context on how authentication works across my-backend and my-frontend."

poll_contextNew

Retrieves the status and result of a request created by request_context.

While the agent works, the response carries a status of QUEUED or RUNNING and no context; keep working and poll again. On completion it carries the synthesized context. A first poll after 30 to 45 seconds, then every 20 to 30 seconds, is a good cadence. Request IDs are not interchangeable between tool generations: an ID from request_task_context cannot be polled here.

Parameters

When to use

After every request_context call. Poll on a schedule rather than in a tight loop, and do other useful work between polls.

Example prompt

"Check whether my context request has finished."

get_codebase_names

Returns all codebases available in your Driver organization. Most other Driver tools require a codebase name — call this first to discover valid names.

Parameters

When to use

Call this at the start of any session before using other tools. Pass include_metadata=true when you need to identify which codebases are relevant to a multi-repo task.

Example prompt

"What codebases are available in Driver?"

get_branches

Returns all branches for a codebase that have completed documentation, with an indicator for the default branch.

Parameters

When to use

Before querying documentation for a specific branch. Use the returned branch names in the optional branch_name parameter of other tools.

Example prompt

"What branches does Driver have documentation for in my-backend?"

get_atlas_indexNew

Returns the codebase atlas index: a thematic map of the whole codebase organized by what its subsystems do rather than by directory. Sections group code that works together even when it lives in different trees, which is how cross-directory subsystems surface.

The response carries the rendered page plus coverage accounting, so a page that looks thin is distinguishable from one that is genuinely empty. Read that accounting before concluding something is absent. Section entries advertise routes to follow with get_atlas_detail.

Parameters

When to use

First, for orientation. Use it to answer where something lives, which subsystems exist, or where a change that spans directories should start, before drilling into files.

Example prompt

"What subsystems does my-backend have, and which one owns billing?"

get_atlas_detailNew

Opens one atlas page by id. Given a section route the index advertises, it returns that section's narrative, its coupling rules, its related sections, and its member files. A section whose narrative has not been generated yet serves its computed facts and members instead, and says so.

Passing a repo-relative file path instead of a section route does a reverse lookup: it returns the sections that own that file, each with its role. An empty list means the file is unmapped, not that it is missing.

Parameters

When to use

After get_atlas_index identifies a relevant section, or when you have a file and want to know which subsystems it belongs to.

Example prompt

"Open the payments section of the atlas for my-backend."

get_code_map

Explores directory structure and returns every file and directory annotated with a pre-computed description of its purpose and contents. Supports adjustable depth and pagination for large trees.

Parameters

When to use

Finding relevant files, understanding directory structure, and exploring unfamiliar areas of a codebase. Use with get_file_documentation to drill into specific files.

Example prompt

"What files handle authentication in my-backend?"

get_related

Returns precomputed relationship context for a file or directory: dependency, mirror, and co-change edges (each with a coupling verdict), type-membership groups, and, for directories, folder relationship narration. Paths are repo-relative; pass an empty string or . for the codebase root.

An empty payload is a valid baseline: it means no precomputed connectivity exists for that node. Treat unlisted edges as unknown, not absent. Large type-membership groups are budget-cut to one-line routing entries in the default view; re-query the same path with symbols=['TypeName'] to expand a specific group's rows in full. The symbols filter narrows results within a single file or directory's doc — it is not a standalone symbol search, and it does not find call sites across the codebase.

Parameters

When to use

Understanding how a file or directory connects to the rest of the codebase: what it depends on, what mirrors it, what changes alongside it, and which types it participates in. Start with a path — this tool is addressed by file or directory, so call it after get_code_map identifies a relevant path. Then pass symbols to expand a group that was summarized to routing entries.

Example prompt

"What is related to src/auth/middleware.ts in my-backend?"

get_source_file

Returns the actual source code of a file with line numbers. Use when you need to see exact implementation logic, control flow, or full code context beyond what symbol-level documentation provides. Supports pagination for large files.

Parameters

When to use

When you need to read the exact implementation of a file — control flow, inline logic, or precise line references. Complements get_file_documentation, which gives structured symbol-level information. If you have local access to the codebase, prefer native file reading tools instead.

Example prompt

"Show me the source code for src/auth/middleware.ts"

glob_files

Finds files in a codebase by path pattern and returns their paths, relative to the codebase root. Use it to discover where files live before reading or searching them.

Patterns use fnmatch semantics, which differ from shell globbing in one way worth knowing: * matches any characters including /. That means *.py already matches nested files, and **/*.py is equivalent to it. Matching is case-sensitive.

Parameters

Returns

A list of matching file paths, relative to the codebase root.

When to use

Locating files by name or extension when you know the shape of the path but not where it sits. Pair it with grep_source to search the contents of what you find, or with get_code_map when you want described structure rather than a flat path list.

Example prompt

"Find every migration file in my-backend"

grep_source

Searches a codebase's source with a regular expression and returns matching lines with the surrounding context. Use it to locate a symbol's definition or call sites, a string or config key, or any pattern across the codebase.

Patterns use RE2 syntax. Dot-path files such as .github/ are included in the search. On a very large codebase the first search may report that the source tree is being prepared; retry shortly and it will complete.

Parameters

Returns

Each match carries its file_path, line_number, line_content, and two lines of context on either side. Alongside the matches, the response reports total_matches and whether the result set was truncated, how many files were searched and how many held a hit, and the codebase coverage of the search as manifest_total and missing_count.

Read those coverage fields before concluding a pattern is absent. When missing_count is above zero, some files were not searched, so no matches means the pattern was not found in what was covered rather than that it does not exist. Narrowing path_glob or retrying is the way to close the gap.

When to use

Finding an exact string, identifier, or pattern, which is not a good fit for Driver's precomputed context. Reach for get_related or change_impact instead when the question is about relationships between symbols rather than literal text. If you have local access to the codebase, prefer your own search tools.

Example prompt

"Where is STRIPE_WEBHOOK_SECRET referenced in my-backend?"

change_impactEarly Access

Reports structured dependency graph and relationship information for a symbol. Provided by deterministic syntax tree computations. Useful generally and to understand the "blast radius" of changing a symbol.

The default mode='summary' answers "how big is this change" with exact counts of various kinds of relationships, and no detail rows. That is cheap enough to run speculatively, or once per changed symbol in a diff. Follow up with one of the other modes described below for rich details.

Address the symbol by name, fully-qualified name, or qualified suffix, in either separator spelling. resolve_config, httpx.Client.request, and Client::request all work. Never pass a language: every analyzed language is searched. For an enum, query the variant rather than the type, since Role.admin returns the sites that branch on the variant while Role returns only the fields declaring the type. Union across variants yourself.

Parameters

Returns

A resolution status, the resolved entity, the path_root that section paths are relative to, and the commit_sha the answer was computed from. Depending on mode, one section of counts or grouped rows, alongside hits_in and no_hits_in listing the languages searched, and caveats where the snapshot qualifies a claim. When the symbol is ambiguous the answer lists ranked candidates instead of a section; re-run with file_hint.

Sections are grouped by file and never truncated: per-file counts sum to the section total, so the index is a complete work list. Fan out over it and check the sum to prove nothing was missed. A very large index coarsens to directories rather than dropping rows. For Python tests, the file and row id compose into a runnable pytest node id; elsewhere a row id addresses the symbol within its file, and the file is the unit a test runner takes.

The graph carries reference coupling: calls, inheritance, type references, and enum-variant reads, followed transitively. Coupling that travels through a shared literal rather than a reference produces no edge, which covers config and environment keys, feature-flag names, SQL and schema text, generated fixtures, and any contract a frontend restates as a string union. So a language listed in no_hits_in is unverified rather than unaffected, and a zero total is strong evidence rather than proof. Confirm those cases with grep_source.

Answers reflect the codebase's last analyzed commit. Uncommitted work is never included.

When to use

Before changing a symbol, to size the change and find the tests that cover it. Reach for it when the coupling is a real symbol-to-symbol reference, it runs more than one hop deep, and the count is too large to eyeball. mode='impact' is the case text search cannot reach, since everything it returns is two or more hops from the symbol you named, and mode='tests' maps a symbol to the tests that reach it through fixtures, repositories, and services, which is not reconstructible by searching text.

Example prompt

"What breaks if I change the signature of DriverValidationError?"

get_changelog

Returns a high-level development timeline organized by year and month.

Parameters

When to use

Understanding development history, major feature introductions, and architectural decisions over time. Use to identify a relevant month before drilling in with get_detailed_changelog.

Example prompt

"What has changed in my-backend recently?"

get_detailed_changelog

Returns detailed commit-level information for a specific month.

Parameters

When to use

Deep-diving into why specific changes were made during a given month. Call get_changelog first to identify the relevant time period.

Example prompt

"What happened in my-backend in January 2026?"

get_registered_content_list

Lists all registered content documents accessible to you, including both static pages and auto-updating codebase documents. Use this to discover available content before fetching it.

Parameters

When to use

Before calling fetch_registered_content to discover what content names are available. Also useful for auditing what documents have been registered to your organization.

Example prompt

"What registered content is available for my-backend?"

fetch_registered_content

Retrieves the full content of a registered document by name, including its markdown content and metadata.

Parameters

When to use

Reading a specific registered document by name. Call get_registered_content_list first to discover available content names.

Example prompt

"Fetch the API design guidelines document"

register_content

Registers a new content document. Supports two types:

• Static content (auto_update=false) — a markdown document stored as a page. Can be associated with zero or more codebases. Documents without codebase associations are org-scoped and visible to all members of the organization.
• Auto-updating content (auto_update=true) — a document that is automatically updated when the associated codebase changes. Requires exactly one codebase. Provide a description_or_goal that guides updates.

Parameters

When to use

Adding new documentation — design decisions, runbooks, API guidelines, or any content you want your agent to access in future sessions. Use auto-updating content for documents that should stay current with codebase changes.

Example prompt

"Register our API design guidelines as a document in Driver"

remove_registered_content

Permanently deletes a registered content document by name. This action cannot be undone. The agent will ask for confirmation before proceeding.

Parameters

When to use

Removing outdated or incorrect registered documents. Use get_registered_content_list first to confirm the exact content name.

Example prompt

"Remove the old API guidelines document from Driver"

Deprecated tools

These six tools still work today. Each one is replaced by a tool above. We plan to remove them on October 1, 2026, so migrate by September 30, 2026.

request_task_contextDeprecated

Deprecated. This still works today. Use request_context and poll_context instead. We plan to remove it on October 1, 2026. Migrate by September 30, 2026.

The primary Driver tool, and the entry point for deep, task-specific context. Runs a specialized context agent server-side that reads architecture docs, navigates code structure, and synthesizes high-signal context tailored to your task. Use BEFORE planning, implementing, debugging, or refactoring.

Non-blocking: this dispatches the work and returns a request_id immediately. It does not return context directly. Call poll_task_context with that request_id to check status and retrieve the result once it's ready.

The context agent typically takes 1-3 minutes. Because submitting is asynchronous and cheap, the effective pattern is: submit early, fire several requests in parallel (one per distinct question or area), do other useful work while they run, and poll on a schedule. Independent requests run concurrently, so there is no need to wrap calls in sub-agents.

Parameters

Returns

A request_id, immediately. Pass it to poll_task_context to retrieve the synthesized context once the agent finishes.

When to use

Start here for any non-trivial task. Call get_codebase_names first to resolve the codebase name, then provide a rich task description. This tool replaces iterative exploration for planning and implementation tasks.

Collect task-specific deep context with Driver MCP tools →

Example prompt

"I need to add rate limiting to the API layer in my-backend. Gather context for me."

poll_task_contextDeprecated

Deprecated. This still works today. Use request_context and poll_context instead. We plan to remove it on October 1, 2026. Migrate by September 30, 2026.

Retrieves the status and result of a context request created by request_task_context. Pass the request_id it returned.

• While the agent works (QUEUED or RUNNING): returns the status and the original request input, no context yet. Keep working and poll again.
• When done (COMPLETED): returns the synthesized context, plus the input.
• On failure (FAILED or CANCELLED): returns the status and an error message.

Parameters

When to use

After submitting one or more requests with request_task_context. The agent typically takes 1-3 minutes, so a good rhythm is to first poll after about 30-45 seconds, then every 20-30 seconds, doing other work between polls. With several outstanding requests, poll each in turn and collect the ones that have finished. Polling is safe to repeat; a completed request returns the same result for a limited retention window.

Example prompt

"Check on the context requests I submitted and pull in whichever are ready."

gather_task_contextDeprecated

Deprecated. This still works today. Use request_context and poll_context instead. We plan to remove it on October 1, 2026. Migrate by September 30, 2026.

Runs a specialized context agent server-side that reads architecture docs, navigates code structure, and synthesizes high-signal context tailored to your specific task — saving your context window. Use BEFORE planning, implementing, debugging, or refactoring.

Synchronous: blocks for the full agent run, typically 1-3 minutes, then returns the synthesized context directly. A dropped connection loses the result, which the request/poll pair avoids. To run multiple calls in parallel, wrap each in a native sub-agent.

Parameters

When to use

Existing workflows that already depend on the synchronous, single-call contract. For new usage, prefer request_task_context + poll_task_context.

Collect task-specific deep context with Driver MCP tools →

Example prompt

"I need to add rate limiting to the API layer in my-backend. Gather context for me."

get_architecture_overviewDeprecated

Deprecated. This still works today. Use get_atlas_index for orientation, then get_atlas_detail to open the section you need. We plan to remove it on October 1, 2026. Migrate by September 30, 2026.

Returns a comprehensive architecture document that covers system structure, key components, design patterns, and relationships.

Parameters

When to use

Start of any task that requires broad codebase understanding. This is the single most valuable tool for grounding the agent in system-level context.

Example prompt

"Show me the architecture of my-backend"

get_llm_onboarding_guideDeprecated

Deprecated. This still works today. Use get_atlas_index for orientation, then get_atlas_detail to open the section you need. We plan to remove it on October 1, 2026. Migrate by September 30, 2026.

Returns a guide optimized for AI agents. It covers navigation tips, key entry points, coding conventions, and cross-references to important files.

Parameters

When to use

Start of a session to build broad codebase familiarity. Pairs well with get_architecture_overview for comprehensive orientation.

Example prompt

"Get oriented with my-backend"

get_file_documentationDeprecated

Deprecated in part. This still returns a file's purpose. Its richer symbol documentation is replaced by get_related for relationships, change_impact for a symbol's blast radius, and get_source_file or grep_source for exact implementation. We plan to remove it on October 1, 2026. Migrate by September 30, 2026.

Returns symbol-level documentation for a specific file: functions, classes, interfaces, imports, and their descriptions — generated from static analysis. Supports pagination for large files.

Parameters

When to use

Understanding the signatures, types, and purpose of symbols in a specific file. Use after get_code_map identifies the relevant file path. Prefer this over get_source_file when you need structured symbol information rather than raw implementation logic.

Example prompt

"Show me the documentation for src/auth/middleware.ts"