# What an MCP server provides

> **What you will learn**
> The three kinds of thing an MCP server exposes and what each is for. And why
> writing good tool descriptions matters more than you would think.

## The three

| Kind | What it is | Character |
|---|---|---|
| **Tools** | actions the agent **calls** | active |
| **Resources** | material the agent **reads** | passive |
| **Prompts** | pre-prepared **instruction templates** | a person picks |

In practice most of it is **tools.** The other two are conveniences.

## 1. Tools — the one you use most

Actions the agent can invoke. Each tool looks like this:

```
Name:        check_stock
Description: Looks up current warehouse stock by product code.
             If stock is in several warehouses, returns it split by warehouse.
Arguments:   product_code (string, required)
             warehouse_code (string, optional — omit for all)
Returns:     list of quantities by warehouse
```

### The description matters more than you think

**The model reads this description to decide when to use it.** A poor
description means it gets used when it should not, or not used when it should.

```
✗ Description: "stock lookup"
   → what stock, and when to use it, is unknown

✓ Description: "Looks up current warehouse stock by product code.
                This is physical stock, not sellable quantity.
                To exclude reservations, use check_reservations alongside it."
   → contains when to use it and what to watch out for
```

**Tool descriptions are documentation written for the model, not for people.**
But the technique is the same as writing for people — what it does, when to use
it, what to be careful about.

### Names matter too

Several similar names and the model gets confused.

```
✗ lookup1 / lookup2 / get_data
✓ check_stock / check_order / check_customer
```

## 2. Resources — material to read

If a tool "does something," a resource says **"here is some material."**

```
Resource examples:
  the company policy handbook (document)
  the product catalogue (document)
  the current project's file list
```

The difference from tools is **who initiates.**

| | Tool | Resource |
|---|---|---|
| Who starts | the model decides and calls | a person selects it in, or the model reads it |
| Character | action | material |
| Example | "look up the stock" | "here is the handbook" |

In practice, putting **frequently referenced documents** in as resources is
convenient. You do not have to paste them every time.

## 3. Prompts — prepared instruction templates

Frequently used instructions, prepared and offered by the server.

```
Prompt: "PR review"
Body:   Review the changes below.
        - are there security issues
        - are any tests missing
        - does it follow our code conventions (attached)
```

A person picks it from a list. Think of it as **a device that saves you
rewriting [the four parts of a good instruction](/guide/ai-intent-context) every
time.**

## The three working together

```mermaid
graph TD
  P["Prompt: 'PR review'<br/>selected by a person"] --> M["Model"]
  R["Resource: code conventions<br/>provided as reference"] --> M
  M -->|"calls when needed"| T1["Tool: fetch the changes"]
  M -->|"calls when needed"| T2["Tool: run the tests"]
  T1 --> M
  T2 --> M
  M --> O["Review result"]
```

## In Connect

Attach an MCP server in [HyperTeams Connect](/guide/cn-agents-intro) and its
tools appear **in the agent list as `APP`.** You can decide per workspace which
tools are on.

The reverse direction works too — Connect itself becomes an MCP server, so an
external client (Claude Code and the like) can use this workspace as a tool.

## Common misconceptions

### "Should I use a resource or a tool?"

**Action means tool, material means resource.** If unsure, ask: "does this change
or execute something?" If yes, it is a tool.

In practice most things get built as tools. Even material works well as a tool
like `get_document(name)`, so the model fetches it when it needs it.

### "Can I write the tool description roughly?"

The most common mistake. **Most cases of a model picking the wrong tool come from
a poor description.** A meaningful share of the time spent building a tool should
go into writing its description.

---

## Check yourself

**1. Why does a tool description matter?**

<details>
<summary>Answer</summary>

**Because the model reads it to decide when to use the tool.** A poor
description means it gets used when it should not and skipped when it should be
used. Most wrong-tool selections trace back to poor descriptions.
</details>

**2. How do you distinguish a tool from a resource?**

<details>
<summary>Answer</summary>

**Action means tool, material means resource.** Ask "does this change or execute
something?" In practice material is often built as a lookup tool anyway.
</details>

**3. What do prompts (templates) save you?**

<details>
<summary>Answer</summary>

**Rewriting the same instruction every time.** Frequently used instructions are
prepared in advance and a person picks one from a list.
</details>

---

More tools brings a new problem →
[When you have too many tools](/guide/mcp-too-many-tools)