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.
| 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.
Actions the agent can invoke. Each tool looks like this:
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.
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.
Several similar names and the model gets confused.
If a tool "does something," a resource says "here is some material."
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.
Frequently used instructions, prepared and offered by the server.
A person picks it from a list. Think of it as a device that saves you rewriting the four parts of a good instruction every time.
HyperTeamsgraph 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"]Attach an MCP server in HyperTeams Connect 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.
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.
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.
1. Why does a tool description matter?
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.
2. How do you distinguish a tool from a resource?
Action means tool, material means resource. Ask "does this change or execute something?" In practice material is often built as a lookup tool anyway.
3. What do prompts (templates) save you?
Rewriting the same instruction every time. Frequently used instructions are prepared in advance and a person picks one from a list.
That is this part. Next, the methodology that turns all of this into how you work every day → What agile solved and what still blocks
Name: check_stockDescription: 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✗ 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✗ lookup1 / lookup2 / get_data✓ check_stock / check_order / check_customerResource examples: the company policy handbook (document) the product catalogue (document) the current project's file listPrompt: "PR review"Body: Review the changes below. - are there security issues - are any tests missing - does it follow our code conventions (attached)