Reading & Writing Real Data Through Claude

Now the Fun Part

You've connected some servers. Now you get to use them — and this is where MCP stops being a concept and starts saving you real time.

The beautiful thing: you don't learn any new commands here. You just talk to Claude in plain English, like you always have. The difference is that now Claude can reach into your live tools to answer. This lesson shows you the kinds of requests that work, what Claude actually does behind the scenes, and how to phrase things to get good results.

There are two modes to understand: reading (pulling information in) and writing (changing something out there). They feel very different, so we'll take them one at a time.

---

Reading: Pulling Live Data Into the Conversation

Reading is the safe, low-stakes side. Claude fetches information and shows it to you. Nothing changes in your tools. This is the best place to start, because mistakes cost you nothing.

Querying your database

With a database server (like Supabase) connected:

"How many users signed up in the last 7 days? Just give me the number."

Behind the scenes, Claude figures out the right query, runs it through the database server, and reports back. You can keep going conversationally:

"Now break that down by day, and tell me which day had the most signups."

You never wrote a line of SQL. Claude wrote it, ran it, and translated the result into plain English.

Reading from GitHub

"List the open issues on my project repo, sorted by how recently they were updated."

"Read issue #42 and explain in plain language what the user is asking for."

Reading from Notion

"Find the page called 'Q3 Roadmap' in our Notion and summarize the top three priorities."

What "reading" looks like step by step

When you ask a read question, here's the dance:

1. You ask in plain English.
2. Claude picks a tool — e.g. mcp__supabase__query — and writes the actual request.
3. Claude asks your permission the first time (you'll see a prompt; more on this in Lesson 4).
4. The server runs it and returns raw data.
5. Claude translates the raw data into a clear, human answer.

You see step 1 and step 5. Steps 2–4 happen in seconds.

---

Writing: Letting Claude Change Things Out There

Writing is the powerful, higher-stakes side. Now Claude isn't just looking — it's doing. Creating an issue, updating a page, inserting a row. These actions are real and they stick. Claude will always ask before it writes, but you should still be deliberate.

Creating a GitHub issue

"Create a GitHub issue titled 'Login button is misaligned on mobile' with a short description explaining that the button overflows its container on screens under 400px. Label it 'bug'."

What Claude does: drafts the issue title, body, and labels, shows it to you, asks for permission, and on your approval calls the GitHub server to create it. You'll get back the new issue's number and link.

Updating a Notion page

"Add a new bullet to the 'Launch Checklist' page in Notion: 'Set up the welcome email automation.' Put it under the 'Marketing' section."

Claude finds the page, figures out where the section is, drafts the change, and asks before writing it.

Inserting into a database

"Add a new row to the waitlist table with email 'jane@example.com' and source 'twitter'."

This one is real data going into your real database. Claude will show you exactly what it's about to insert and wait for your go-ahead.

The golden habit: review before you approve

When Claude is about to write, it shows you what it'll do before doing it. Read that summary every time. Ask yourself: is this the right page? The right table? The right values? It takes two seconds and it's your last checkpoint before something real happens.

---

Chaining Tools: Where MCP Gets Genuinely Powerful

The real magic is when Claude combines reading and writing across multiple tools in one request. Because every server speaks the same protocol, Claude can move between them fluidly.

"Look at the newest 'bug' issue on our GitHub repo, then create a Notion page in our 'Bug Triage' section that summarizes it and lists three questions we should ask the reporter."

In one breath, Claude:

• reads from GitHub,
• thinks about it,
• and writes to Notion.

Another example:

"Find any users in our Supabase database who signed up but never completed onboarding, and create a GitHub issue listing how many there are so we remember to follow up."

This is the operator mindset from Lesson 1, made concrete. You describe an outcome that spans your whole toolset, and Claude orchestrates it.

---

How to Phrase Requests So They Work

A few habits make a big difference:

And when you're not sure what a connected server can even do, just ask:

"What can you do with the Notion connection? List the actions available to you."

Claude will tell you the tools that server exposes.

---

When Something Doesn't Work

A few common situations and what they mean:

• "I don't have access to that tool." The server probably isn't connected, or isn't authenticated. Run claude mcp list to check its status, and /mcp to log in if needed.
• Claude returns nothing or an empty result. Often the data genuinely isn't there (no matching rows, no such page). Ask Claude to double-check its query.
• Claude asks permission and you're not sure. That's working as intended — the next lesson is all about reading those prompts and deciding well.

---

Summary

• You use connected tools by asking Claude in plain English — no new syntax to learn.
• Reading pulls live data in and changes nothing — the safe place to start (query your DB, read issues, summarize Notion pages).
• Writing makes real changes out there (create issues, update pages, insert rows). Claude always asks first — review the summary before approving.
• The biggest wins come from chaining tools: read from one, write to another, in a single request.
• Phrase requests with the tool/place named and the output you want specified; ask Claude what a server can do if you're unsure.