Start here

DevHub is a desktop application. Its MCP server gives you tools for four things: the knowledge vaults (notes about how the work is done and why), the repository index (symbols, callers, impact), plans and investigations (work split into steps that you take one at a time), and files and scripts in the repositories you were given.

Use these tools instead of searching on your own. A vault already holds the answer to most “how” and “why” questions, and the index answers “where is it” and “what breaks” without reading every file.

1. The user starts the MCP server in DevHub. It runs only while the user is signed in. See MCP server.
2. The user copies the MCP address from the Dashboard (the MCP server card, Copy MCP endpoint) and pastes it into your client, or uses Set up a folder on Harnesses Manage so DevHub writes the client files. See Connect an AI client.
3. You do not know the address and cannot guess it. If DevHub tools are missing from your tool list, tell the user to start the MCP server and connect the client. Do not look for the address in files.
4. Your client may show DevHub tools by name only. Load the schema of a tool before you call it.

When you want to	Call	Instead of
start a task	context_pull (the user may have queued notes and symbols for you)	searching first
know which repositories you may touch	workspace_list	guessing a workspaceId
know which vaults you may read or write	vault_list	guessing a vaultId
see what a vault holds	vault_overview	walking folders
learn how or why something works	knowledge_search on the repository vault	reading source first
find a note by words in it, or get its path	vault_files_search	building a path from a title
read a note	vault_file_read with the path from a listing or a search	opening files on disk
see the shape of a codebase	repo_overview	walking folders
find a function, class or file	repo_symbol_search	files_search for a definition
learn who calls something	repo_callers	grep for the name
learn what a change would break	repo_impact	reading every caller
find a string, a setting or a comment	files_search	the shell
change a file	file_replace or file_edit	file_write on an existing file
check your change	npm_script_run with a declared script, then repo_changed	saying it is done
look into something before building it	investigation_list, then investigation_create	notes in your answer
do work longer than one commit	plan_ready, plan_claim, then the step	a to-do list in your answer
record what went wrong	learning_note	silence
record how this user wants the work done	memory_note	silence
find a skill, rule or persona that exists	library_list	writing your own
ask another configured agent	agent_list, then agent_run	doing it twice

1. context_pull. It empties the queue; use context_get if somebody else still needs it.
2. workspace_list and vault_list if you were not given a workspaceId and a vaultId. Take them from the results. Never invent them.
3. vault_overview on the repository vault before you change code.
4. knowledge_search for the question, before you open source.
5. repo_index_status. If it says the index is stale or missing, repo_index_refresh. Then use the repo_* tools.
6. Work from a plan? plan_ready first. Never assume a step is free because it looks next.

Search a vault: vault_list gives the vaultId; then knowledge_search with { "vaultId": "<id>", "query": "how does X work" }. Read a hit with knowledge_get (id) or vault_file_read (vaultId, path from the result). If it finds nothing, try vault_files_search.

Find code: workspace_list gives the workspaceId; then repo_index_status, and repo_symbol_search with { "workspaceId": "<id>", "query": "name" }.

Take a plan step: plan_ready lists what is free; then plan_claim with { "planId": "<id>", "stepId": "<id>", "by": "<your name>" }. Work in the working tree it returns, commit, then plan_close with the commit shas and step_log with what you did. See Workflows.

• Pass vaultId on every vault_* call, and workspaceId on every file_*, repo_* and npm_* call.
• Take paths from a listing or a search result, not from a title.
• Read before you write. file_edit and vault_file_edit need the expectedHash and line numbers from the read.
• An error says what to fix. Fix the argument and call again. See Errors.
• Before you say the work is done, run the project’s own checks and look at the result.

• Using the tools
• Workflows
• Limits