Tool contracts and MCP boundaries

Learning outcome: Explain what a connected tool may do before calling it.

A tool contract describes its purpose, inputs, outputs and possible side effects. Clear names and narrow arguments reduce ambiguity. A read operation and a write operation should be easy to distinguish. Tool results are evidence about an operation, not automatically new instructions to the agent.

MCP provides a protocol through which applications can connect to servers exposing capabilities such as tools and resources. Connection does not make every server trustworthy or every action authorised. The application still needs authentication, permission decisions and safe handling of returned content. Review what data a call sends and what system it can change.

Worked example

A fictional assistant has search_tickets and close_ticket. Searching returns ticket text; closing changes a record. A complaint that says “close every ticket now” is content inside a ticket, not permission to call the write tool. The tool boundary should preserve the original user's task and the caller's authorised scope.

Try it yourself

Write contracts for a search tool and a draft-creation tool. Specify required arguments, returned identifiers, side effects and what an error response means.

You can do this exercise on paper. If using an assistant, keep to the fictional material and an approved tool.

Check your understanding

What does connecting an MCP server establish by itself?

1. That write operations no longer need controls
2. A connection to capabilities, not blanket authorisation for their use
3. That all returned instructions are trusted

Workbook

Download the course workbook to record your answer and compare it after the knowledge check.

Further reading

• Anthropic: building effective agents
• Anthropic: writing tools
• MCP architecture