Tools and MCP

A model can only write text, yet AI assistants read files, convert documents and query other models. This lesson shows the trick behind that, tool use, and the standard that lets one tool work in many apps, the Model Context Protocol.

A model cannot do anything by itself

From lesson 1 you know a model only produces tokens. It cannot open a file, fetch a web page or run a command. What it can do is write text in a precise shape that says "please run this tool with these values". The app around it reads that, decides whether to run the tool, and sends the result back. This is called tool use or function calling.

  you ──► app ──► model: "Here is the question, and here are the tools you may ask for."
                  model ──► app: "Call convert_file with path = report.docx"
          app runs the tool (or refuses) ──► result
          app ──► model: "Here is the tool's result."
                  model ──► app: final answer, written from the result
  you ◄── app

The important part: the app runs the tool, not the model. The app decides which tools exist, and can ask you before running one.

Function calling in a chat request

In the OpenAI-style request from lesson 4, you describe the tools in a tools list. Each has a name, a description the model reads to decide when to use it, and its parameters as a JSON Schema (a JSON description of which fields are allowed and their types). An illustrative example:

{
  "model": "example-model",
  "messages": [{ "role": "user", "content": "What's the weather in Chennai?" }],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Current weather for a city",
        "parameters": {
          "type": "object",
          "properties": { "city": { "type": "string" } },
          "required": ["city"]
        }
      }
    }
  ]
}

If the model decides it needs the tool, it does not answer in words. Its message holds a tool call, and finish_reason is tool_calls:

{
  "role": "assistant",
  "content": null,
  "tool_calls": [
    {
      "id": "call_1",
      "type": "function",
      "function": { "name": "get_weather", "arguments": "{\"city\": \"Chennai\"}" }
    }
  ]
}

Your app runs its own get_weather code, then sends a new request with the conversation so far, the assistant's tool call, and the result as a message with the role tool:

{ "role": "tool", "tool_call_id": "call_1", "content": "{\"temp_c\": 31, \"sky\": \"clear\"}" }

The model then writes the answer: "It's 31 °C and clear in Chennai."

Things to notice:

• arguments is text the model wrote. It can be wrong, incomplete or not even valid JSON. Check it before you use it, as you would check any input.
• The model may pick the wrong tool, or call one when it did not need to. Clear names and descriptions help.
• Not every model or endpoint supports tools. In DL Prism, models are tagged with capabilities such as tools, and both its Anthropic-compatible endpoint and its subscription providers refuse requests that include tool definitions, with a 400 error. See Add providers and API keys.

Why a standard: the Model Context Protocol

With plain function calling, every app writes its own tools in its own way. A tool written for one chat app does not work in another.

The Model Context Protocol (MCP) is an open standard that fixes this, like a common plug. A tool is packaged once as an MCP server, and any app that speaks MCP can use it.

Part	What it is	Example
Host	The app you use, with the model inside	A desktop chat app or a coding assistant
MCP client	The part of the host that connects to servers	Built into the host
MCP server	A small program that offers tools	markdrop-mcp, prism mcp

 host app (with the model)
   └─ MCP client ──┬── markdrop-mcp   tools: convert_file, convert_url, …
                   └── prism mcp      tools: prism_chat, prism_explain, …

Besides tools (actions the model can ask for), MCP servers can offer resources (data to read) and prompts (ready-made instructions). Tools are the part you will meet most.

How a client and a server talk

There are two common ways to connect:

• Local: the host starts the server program itself and they exchange messages through its standard input and output. Nothing listens on the network.
• HTTP: the server runs as a network service at an address, and the client connects to it.

The messages are small JSON requests in the JSON-RPC format. The client first asks what tools exist (tools/list), and when the model wants one, calls it (tools/call). A call to Markdrop's convert_file tool looks like this:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "convert_file",
    "arguments": { "path": "/home/you/Documents/report.docx" }
  }
}

The server answers with the result for the model to read:

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": { "content": [{ "type": "text", "text": "---\ntitle: report\n…" }] }
}

You never type these yourself. You ask the host in plain words, and it handles the protocol.

Example: Markdrop's MCP connector

markdrop-mcp lets an MCP client convert files, folders, web pages and YouTube videos to Markdown on your computer. After installing it (a Python package from the release page), you connect it to a client. For Claude Code, the guide gives:

claude mcp add markdrop -- markdrop-mcp --root ~/your-folder

Tool	What it does
convert_file	Converts a local file. Can save the result to output_path
convert_url	Converts a web page or a linked file
convert_to_markdown	Converts a file:, http:, https: or data: address
youtube_to_markdown	Gets a video's details and transcript
convert_directory	Converts every matching file in a folder into .md files
list_supported_formats	Lists the formats it can convert and the folders it may read

Then you can ask, for example, "convert the PDFs in my reports folder to Markdown", and the client picks the tool.

Notice how it limits itself:

• It only reads files inside allowed roots: by default the folder it was started in, ~/Documents and ~/Downloads, or the folders you give with --root. A link inside an allowed folder cannot point it outside.
• It refuses web addresses on private or local networks, and limits downloads to 50 MB.
• In HTTP mode (--http, at http://127.0.0.1:3002/mcp by default) clients must send a bearer token from MD_MCP_TOKEN. Without a token, anyone who can reach the port could read files in your allowed roots.

See MCP connector.

Example: DL Prism's MCP server

prism mcp is built into the DL Prism gateway. It lets a coding assistant ask another model, perhaps a cheaper or local one, for help during a session. It talks to the running gateway, so your routing rules, failover and budget still apply.

claude mcp add dl-prism -- prism mcp

Tool	What it does
prism_chat	Sends a prompt to auto or a named model and returns the reply, saying which model answered
prism_explain	Returns the routing decision for a prompt, without calling a model
prism_models	Lists your models
prism_usage	Shows this month's spend and budget

To share the setup with a project, the guide shows an .mcp.json file. Note that its API key value is left empty: a file you check in must not hold secrets. See Claude Code MCP server.

Stay safe

• An MCP server runs with your permissions. It can do anything your user account can, within what its code allows. Install servers only from sources you trust, as you would any program.
• Give the least access that works. Use Markdrop's --root to allow one project folder, not your whole home folder.
• Review actions before they run. Reading is low risk; writing files, deleting, sending messages and running shell commands are not. Keep your host's approval prompts on for those, and read each command before you allow it.
• Tool results are untrusted text. A web page or file a tool fetches goes into the model's context and may contain instructions aimed at the model. This is prompt injection, covered in lesson 6.
• Keep HTTP servers private. Bind to 127.0.0.1 and set a token, as Markdrop's guide insists for HTTP mode.

Check yourself

QuizTools and MCP

Question 1 of 6

When a model "uses a tool", who actually runs the tool?

Score: 0

What you learned

• A model cannot act; it writes a structured tool call, and the app decides whether to run it.
• In function calling, tools are described with a name, a description and a JSON Schema; results come back as tool messages.
• Tool arguments are model-written text: check them.
• MCP is a standard plug: hosts contain clients, servers offer tools, and they talk JSON-RPC (tools/list, tools/call) locally or over HTTP.
• Markdrop's MCP server converts files within allowed roots; Prism's lets an assistant consult other models through your gateway.

Next steps

• Use AI safely
• Markdrop MCP connector
• DL Prism companions