Teaching Claude to use your tools

A useful answer sometimes sits one folder away from the conversation. A note contains the comparison, a database contains the records, or a small script can calculate the result. The assistant still needs a way to reach it.

Pasting the information into chat works, but someone has to find it first. Model Context Protocol, usually shortened to MCP, lets a tool do that retrieval. The interesting change is that a question can lead to a lookup, and the lookup can supply evidence for the answer.

Give the assistant a way to look

An MCP server is a program that exposes capabilities to a client such as Claude Code. For a tool, it supplies a name, a description, and a schema describing the inputs. The assistant can request a call; the client sends it to the server; the handler does the work.

Consider a folder of notes about local models. The question is simple: which note compares memory usage? A useful tool can search the folder and return a filename with a short excerpt. The assistant then has something specific to inspect rather than a reason to guess.

{
  "name": "search_notes",
  "arguments": {
    "query": "memory"
  }
}

The model doesn't gain a permanent copy of the folder. It receives the result of a particular call. A later question may need another search, another file, or a narrower request. That distinction makes the connection easier to reason about.

The program behind the conversation

In a local stdio setup, Claude Code starts a process and communicates through standard input and output. That process can read a permitted directory or call an existing API. It doesn't need a listening web port. Remote servers can use HTTP, with authentication appropriate to the service.

“Local” describes where the server runs. It doesn't describe where the model runs. If a local server sends a note back to a cloud-based assistant, that note enters the assistant's context. Local retrieval and local inference are separate choices.

Access comes from the server and the identity it uses. A database credential, an allowed folder, and the client's permissions each affect what a call can accomplish. Tool descriptions explain operations; they don't enforce access by themselves.

Try one connection in a small folder

The filesystem reference server makes the setup visible. Claude Code already has native file tools, so the point of this example is to learn the connection pattern. Use a disposable folder containing a couple of sample notes. Node.js and Claude Code should already be installed.

Prepare the folder

mkdir -p ~/mcp-demo
cd ~/mcp-demo

Add model-comparison.md and reading-list.md with a few sentences each. Small, recognizable files make it easy to tell whether the server reads the intended content.

Register the process

claude mcp add --transport stdio --scope local notes -- npx -y @modelcontextprotocol/server-filesystem "$(pwd)"

notes names the connection. Everything after -- launches the server. Local scope associates the registration with this project; it is not a read-only permission setting. This follows Claude Code's stdio configuration.

The filesystem server includes write operations. Inspect its tool list and active allowed directories, including any client-supplied roots. A small demo folder gives the experiment a boundary that is easy to inspect.

Check what actually connects

claude mcp list
claude mcp get notes

Start Claude Code from the sample folder and ask it to list the notes, then read the comparison. Check the reported filenames and returned text. A registration entry shows how to start a server; a successful call shows that the connection works.

Configuration is a launch recipe

An equivalent project-level entry in .mcp.json records the executable and its arguments. Replace the path with the absolute location of the demo folder.

{
  "mcpServers": {
    "notes": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/absolute/path/to/mcp-demo"]
    }
  }
}

The entry doesn't contain the tool implementation. That lives in the launched program. A custom Python or Node server uses the same arrangement: a client configuration starts it, and the program supplies its capabilities.

Inspect the result as carefully as the request. A tool name and input explain what was asked for. The source and returned passage establish what the answer can rest on. Missing sources or hidden truncation make that evidence harder to check.

Make the result worth bringing back

Start with one question the assistant cannot answer from its current context. A notes tool might return filenames and excerpts. A database tool might list tables, then describe one table. Clear names and distinct operations make the next call easier to choose.

Output size matters too. Returning an entire archive to answer a question about one passage adds reading work and can hide the relevant detail. A focused result should include its source and disclose when it is incomplete, so the next request can narrow the search.

The same pattern leads naturally to building a SQL Server MCP: start with the question, expose the operation it needs, and return enough evidence to check the answer.

A connection that earns its place

Inspect or remove the registration with claude mcp get notes and claude mcp remove notes --scope local. Removing the entry doesn't delete the sample notes.

MCP becomes useful when it closes a specific gap between a question and the information needed to answer it. One understandable tool, a visible boundary, and a result that can be inspected make a better starting point than a long list of connections. Once that first lookup makes sense, adding another capability becomes a deliberate choice.