What connecting a tool actually does

MCP — the Model Context Protocol — is how Claude talks to things that aren't your filesystem. A server sits between Claude and an outside service, publishing a list of tools: search these pages, read this message, create that event. Claude calls them; the server does the work against the real service.

   you ──asks──▶ Claude ──tool call──▶ MCP server ──API──▶ service
                              ◀── results ──         ◀── data ──

  Trust 1: the server holds (or brokers) your credential
           for the service.
  Trust 2: whatever the service returns enters your session
           as content Claude reads.

Both halves matter and people usually only think about the first. Yes, an MCP server can see the data you authorise it to see — that's the obvious risk, and it's why the provider matters. The second is subtler: everything a tool returns comes back into the conversation, and text in a page or an email can contain instructions aimed at Claude. That's a whole lesson later in this level.

So evaluating a connector is five concrete checks, not a feeling. Who owns it — the service itself, or a third party? Is it documented well enough that you can tell what it does? What scopes does it ask for, and are they the minimum for your task? Is it maintained? And can you remove it cleanly, including revoking access at the source? A "no" on ownership or scopes is usually decisive.

Once connected, read the tool list before using it. Names are informative: search_pages and get_page are reads; create_page, update_page, delete_page are writes. Sorting them into two columns takes a minute and tells you the blast radius of the connection you just made.

Loading your workspace…