You've already been using tools. Every time a Charm generates an image, fetches a web page or searches your documents, it's calling a tool. That's been the model from the start.

What changes with MCP (Model Context Protocol) is this: you can now add 

 tools. Connect your GitHub repository. Your email. Your data warehouse. Any service that exposes an MCP endpoint is something your Charms can reach — without you having to copy-paste content in as Reference Material or manually import files.

The Charm asks the question. The tool gets the answer. It lands in your document alongside everything else.

Before custom tools, getting external information into a Charm required you to do the lifting: find the document, copy the content, paste it in or attach it as Reference Material. That's fine for a one-off task. It breaks down when the information changes frequently, when there's a lot of it or when you'd rather the Charm just 

A Charm connected to your GitHub repository can answer "what shipped this sprint?" with real pull requests, not a guess. A Charm with access to your CRM can pull the actual deal status before a meeting. A Charm connected to your data warehouse can run the query and tell you what your top customers spent last quarter.

The information stops being something you manage. It becomes something your Charm can reach for.

The temptation when you first set this up is to build a Charm that has access to everything — GitHub, email, Slack, your database, the whole stack. Don't.

 Every tool you give a Charm is listed in its context. That listing takes up space — space you'd rather spend on Reference Materials, document content, and the actual work. A Charm loaded with thirty tools is already working with less available context than one that has three.

 A Charm that touches your production database should not be the same Charm that touches your development environment. A Charm connected to your billing system should not be the same one you hand off for general experimentation. When tools are separated by Charm, mistakes are contained by Charm.

Design your tools the same way you design your personas: one job, one Charm. A research Charm with documentation access. A data Charm with read access to your warehouse. A code Charm connected to your repository. Each sharp. Each bounded.

Remember that when you give a Charm access to something real: it can 

 real things with it. That's the point. It's also why the first connection you make should always be the narrowest one.

Start with read-only access. Test the specific use case you had in mind. Watch what the Charm does with it. Once you've seen it work and understand the pattern, expand permissions deliberately — only to what the next use case actually requires.

This isn't overcaution. It's the same discipline you'd apply to any system that has access to your work. We spent years teaching people not to click unknown email links. Thinking carefully before giving an AI Charm access to something you care about is the same skill — just applied to a new surface.

The tool restrictions you configure when setting up an MCP server exist precisely for this. You can expose only the tools you've decided you're ready to test. Read tools first. Write tools when you know what you're doing.

When a Charm uses a tool during a completion, you don't need to do anything differently. Prompt the way you always do. If the Charm needs to call a tool to answer your question, it does — and the result comes back as part of the response in your document.

If it's the first time a Charm is using a connection you haven't authorized yet, CharmIQ will pause and ask you to grant access. One authorization. After that, it's seamless.

The tool call itself is transparent. What you see is the output — the data, the analysis, the answer — right there alongside your other work. No tab-switching. No copy-paste. The document is still the integration layer.

 — The practical setup: authorizing connections and configuring what your Charms can reach.

 — Once each Charm is focused and equipped, how to run them in sequence on a real problem.

How to extend what your Charms can reach — and why focused tools beat unlimited access.

Giving Your Charms Tools

Tools Are Nothing New

What This Actually Unlocks

One Charm, One Job

Start Narrow, Expand Deliberately

In Practice

Patterns

Next Steps