# Start here > What an AI agent can do with DevHub, how to connect, and which tool to call first for each need. 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. ## Connect 1. The user starts the MCP server in DevHub. It runs only while the user is signed in. See [MCP server](/devhub/features/mcp-server/index.md). 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](/devhub/getting-started/connect-client/index.md). 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 X, call Y | 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 | ## Order at the start of a task 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. ## Three calls you will make first Search a vault: `vault_list` gives the `vaultId`; then `knowledge_search` with `{ "vaultId": "", "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": "", "query": "name" }`. Take a plan step: `plan_ready` lists what is free; then `plan_claim` with `{ "planId": "", "stepId": "", "by": "" }`. Work in the working tree it returns, commit, then `plan_close` with the commit shas and `step_log` with what you did. See [Workflows](/devhub/for-agents/workflows/index.md). ## Rules that save you a failed call - 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](/devhub/for-agents/errors/index.md). - Before you say the work is done, run the project's own checks and look at the result. ## Next - [Using the tools](/devhub/for-agents/mcp-tools/index.md) - [Workflows](/devhub/for-agents/workflows/index.md) - [Limits](/devhub/for-agents/limits/index.md)