Connecting Claude Code to the tools you already use

Two kinds of connection

Sort what you want the agent to reach into two groups. The first extends what it can do: open the page it just changed, check whether last night’s release is healthy. The second removes copying and pasting of information you already have. Both are worth fixing, and the second is usually one command away.

Anything with a command line is already connected

Claude Code runs commands with your permission, in your project directory, using whatever is installed on your machine. There is no integration step. You install the tool as you always would, sign it in once, and note in CLAUDE.md that it exists and what you use it for.

GitHub is the clearest example. The gh command reads issues and their comment threads, opens pull requests and fetches the logs of a failed check. Git covers history, diffs and blame. Between them you can ask the agent to read a ticket, make the change, open the pull request and explain a red check, with nothing configured beyond the login you already have.

The same applies beyond version control. If a tool ships a command line, the agent can use it today:

• Tests and builds Your test runner, linter and build tool are the feedback loop the agent works against. An agent that reads the failure corrects itself instead of handing you plausible-looking code.

• Databases A client pointed at a development database lets the agent inspect a schema and check what a query returns before writing code around a guess. Give it credentials that can only read.

• Hosting and deploys Platform command line tools let the agent see what is running and pull logs when something looks wrong. AppHaven’s CLI and Claude Code skill are read-only for that reason: the agent can confirm a deploy worked and read the build and container logs, while deploys happen on git push.

• Your own scripts The shell scripts your team already keeps in the repository are tools too. A line in the project instructions naming them is usually the whole integration.

Why the command line is the better default

Claude Code’s tool search, on by default, loads MCP tool definitions only when needed, so saving context is not the reason to prefer a command. The reasons that hold up are practical ones.

There is nothing to set up. If the tool is installed and permitted, the agent can use it today, with the login you already have: gh is signed in, and there is no second set of credentials to hand out. It is also the tool your team already knows, so there is one workflow instead of two.

And you can see what happened. A command and its output are plain text: you can read exactly what the agent ran and what came back, and run it yourself when a result looks wrong.

When MCP earns its place

MCP is useful for systems with no suitable command line tool, such as an internal service or a shared document workspace. Browser automation can work through either interface: both a browser CLI and an MCP server can keep a session alive while the agent opens pages, clicks through a flow and reads the console.

Another reason is control. A server can offer a few structured operations with exactly the access they need, which beats a general command line when parsing text output proves fragile or when the agent should get a narrower door than your engineers use.

If you are weighing that up, what MCP servers do in Claude Code covers what one gives you and what it costs. For setting one up, follow the official documentation.

What editor integrations add

Editor and IDE integrations are worth having. The agent still works on the repository on disk, but the conversation sits next to your code and diffs show up where you review them.

They can also add context a terminal does not have: the code you have selected, the diagnostics your language server is reporting, access to a notebook. What an editor integration will not do is connect the agent to your issue tracker or your database. For that, go back to the command line.

Deciding what to connect

Work backwards from the work. For a week, notice what you keep pasting into the conversation and what you keep leaving the session to check. That is your shortlist.

Then take it one item at a time: a command line tool where it does the job well, a server where it adds something useful, read-only access wherever that is enough. Keep the list short, because every connection is another set of credentials and another source of text the agent reads.