Deepthi's Reading

Deepthi's Reading #001

Plugins, Skills, Connectors, MCP, Agents and Codex — explained while I built with them

ChatGPT · Codex · MCP · Connectors

Edition #001 · 6 chapters · 15 min read

Free sample edition

Deepthi's Reading #001

Plugins, Skills, Connectors, MCP, Agents and Codex — explained while I built with them

Come with me while I build something with AI. See the actual questions I asked, understand the tools I discovered, learn how they work in plain English, see what failed, then try it yourself.

Edition #001 runs on two tracks. Track 1, My Journey: what I was trying to build and what actually happened. Track 2, Learn With Deepthi: now that I have met this technology, here is what it really means in language anyone can follow. You need zero technical background to start.

Free to read — no payment neededStart reading Back to the library

Start here

What you'll understand by the end

Not mastery — understanding. By the last page you'll be able to explain these in your own words, even with no technical background.

•what ChatGPT really is, and what it cannot do
•what Codex really is, and what it cannot do
•what Connectors really is, and what it cannot do
•what MCP really is, and what it cannot do
•the difference between what the AI does, what the tool does, and what I do
•why permissions and privacy matter once AI can act on your behalf
•where a real person's judgement is still necessary

The concept ladder — the order I actually learned things

I had an idea worth building

↓

I asked an AI to help me shape it

↓

I learned the AI could explain things but could not act outside the chat by itself

↓

I met the tools that actually do the work

↓

I learned how those tools are connected and permitted

↓

I built something real and watched it break

↓

I learned where my own judgement is still required

Chapter 01

Why Plugins, Skills & Agents lab had to exist

Track 1 · My journey

I kept reading about plugins, skills, connectors and MCP servers and understanding none of it. So I stopped reading and started installing. I kept meeting words like plugin, skill, connector, MCP and agent. Instead of nodding along, I stopped and studied each one, then tried to use them in a real project. This is the notebook of that experiment. The honest test I set myself was simple: if this existed tomorrow, would anyone actually open it twice? Everything in the rest of this book is downstream of that one question. Plugins, Skills & Agents lab is what came out the other side.

Learning checkpoint

Before this chapter

I had a problem I could describe in a corridor conversation, but nothing I could hand to anyone.

After this chapter

I still did not know which tools to use, but I knew exactly who I was building for.

What changed my mind

The problem stopped being a complaint and became a specification.

Can you answer these?

?Can you state the problem in one sentence, without naming a solution?
?Do you know who is holding the screen when your product is used?

Chapter 02

The first conversation

Track 1 · My journey

I did not start with code. I started by describing the thing out loud, in ordinary language, the way I would explain it to a colleague. The build tool answered with a working screen, and that changed the conversation from theory to critique — it is much easier to say what is wrong with something in front of you than to specify it from nothing. These were the exchanges that actually moved the build: Me: "What is the difference between a skill and a plugin?" → A plugin is the box; a skill is one thing inside the box. Me: "Why did it not use the tool?" → Because I described the tool instead of describing the outcome. Me: "Is MCP a product?" → No. It is the protocol tools speak so any assistant can call them. Each of those lines looks small. Together they are the design document. I have stopped writing long specifications; the transcript is the specification.

Learning checkpoint

Before this chapter

A blank project and a chat window.

After this chapter

The shape of the product was decided before a single deliberate design decision was made.

What changed my mind

I learned to treat conversation as a design tool, not as preparation for design.

Can you answer these?

?What is the one sentence in your own notes that decided the architecture?
?Are you describing outcomes, or dictating implementation?

Chapter 03

Building it: ChatGPT, Codex, MCP, Connectors

Track 1 · My journey

I installed plugins one at a time and watched what each one actually changed. A skill turned out to be nothing more than written instructions the model loads when the work matches. A connector turned out to be a login plus a set of allowed actions. An MCP server turned out to be the thing sitting behind the connector, defining the tools and enforcing who may call them. None of these were magic. Every one of them was a boring, explainable piece — and that is exactly why they are worth explaining to people who were told they were complicated. The stack was ChatGPT, Codex, MCP, Connectors. I did not choose it for elegance; I chose it because it let me get a real, usable thing in front of a real person quickly, and because I could change my mind cheaply when the first idea turned out to be wrong. The rhythm mattered more than the tooling. Ship something small, use it honestly, fix the one thing that hurt most, repeat. Most of the good decisions in Plugins, Skills & Agents lab came from that loop rather than from planning.

Track 2 · Learn with Deepthi

ChatGPT

USED — evidence shows I used it

What did I just discover?: That ChatGPT was doing more of the work in this build than I gave it credit for.
What I thought it meant: I assumed it was a technical detail I could pick up later.
What I learned: It shaped what was easy and what was expensive, and therefore what the product became.
What is it, really?: ChatGPT is an AI assistant you talk to in plain language; with plugins and connectors it can also use outside tools.
Think of it like this (analogy): A workshop tool: it does not decide what you make, but it strongly influences what you find yourself making.
How does it actually work?: You send a message. The model predicts a useful response, and if a tool is installed and relevant it may call that tool and use the result.
A little deeper (optional): The model itself only produces text. Tool use is orchestrated by the surrounding product, which runs the call and feeds the result back into the conversation.
Why does this exist?: Most people cannot write code or APIs. It exists to make software capability reachable through conversation.
Why did it matter to my project?: Because the constraints of your tools quietly become the constraints of your product.
Where I used it: Used throughout Plugins, Skills & Agents lab, especially while getting the first working screens in front of people.
Common beginner misunderstanding: People treat confident wording as evidence of accuracy. Fluency and correctness are different things.
What this tool cannot do: It does not know anything that is not in the conversation, its training or a tool result, and it can be fluent and wrong at the same time.
What surprised me: How much of the design pressure came from the tool rather than from the problem.

What happens behind the scenes

What the AI is doing

Interprets the request, decides whether a tool is needed, and writes the answer.

What the tool is doing

Any installed plugin, connector or MCP server performs the real external action.

What I am doing

Frames the problem, supplies context and judges the answer.

What data is moving where?

1.Me → AI: a request
2.AI → tool (if needed)
3.Tool → AI: result
4.AI → Me: an explanation

What is happening right now?

Deepthi writes a prompt

Model decides whether a tool is needed

Tool performs the permitted action

Model explains the result

One thing to remember

Remember this

Choose tools by what they make cheap to change, not by what they make possible.

Try it yourself

Rebuild one screen of your own project with ChatGPT and time it honestly.

Accuracy note: product behaviour checked on 2026-08-15. General concepts are stable; product-specific behaviour can change.

Track 2 · Learn with Deepthi

Codex

EXPLORED — I researched or discussed it

What did I just discover?: That Codex was doing more of the work in this build than I gave it credit for.
What I thought it meant: I assumed it was a technical detail I could pick up later.
What I learned: It shaped what was easy and what was expensive, and therefore what the product became.
What is it, really?: Codex is the coding side of the assistant: it works inside a code environment to read, change and run code.
Think of it like this (analogy): A workshop tool: it does not decide what you make, but it strongly influences what you find yourself making.
How does it actually work?: It reads the project, proposes changes, runs commands in a sandbox and shows you the result for approval.
A little deeper (optional): The host controls the sandbox and approval policy; the model only acts within what that host permits.
Why does this exist?: Explaining code in chat is not the same as changing it safely. Codex exists to let the model work in the codebase with guardrails.
Why did it matter to my project?: Because the constraints of your tools quietly become the constraints of your product.
Where I used it: Used throughout Plugins, Skills & Agents lab, especially while getting the first working screens in front of people.
Common beginner misunderstanding: People imagine it "just fixes things". It makes proposals inside limits you set, and review still matters.
What this tool cannot do: It cannot escape the sandbox or approval policy, and it does not truly know whether a change is correct for your users.
What surprised me: How much of the design pressure came from the tool rather than from the problem.

What happens behind the scenes

What the AI is doing

Reads code, plans and writes edits, and interprets command output.

What the tool is doing

The sandbox runs the commands and enforces what is allowed.

What I am doing

Approves changes, sets the goal and rejects wrong work.

What data is moving where?

1.Me: a task
2.AI: reads the repo and plans
3.Sandbox: runs commands
4.AI: reports back
5.Me: approve or correct

What is happening right now?

Deepthi describes a task

Codex reads the repository

Codex proposes edits

Sandbox runs the commands

Deepthi approves the result

One thing to remember

Remember this

Choose tools by what they make cheap to change, not by what they make possible.

Try it yourself

Rebuild one screen of your own project with Codex and time it honestly.

Accuracy note: product behaviour checked on 2026-08-15. General concepts are stable; product-specific behaviour can change.

Track 2 · Learn with Deepthi

MCP

EXPLORED — I researched or discussed it

What did I just discover?: That MCP was doing more of the work in this build than I gave it credit for.
What I thought it meant: I assumed it was a technical detail I could pick up later.
What I learned: It shaped what was easy and what was expensive, and therefore what the product became.
What is it, really?: MCP (Model Context Protocol) is a shared standard that lets an AI assistant connect to an outside service and use its tools.
Think of it like this (analogy): A workshop tool: it does not decide what you make, but it strongly influences what you find yourself making.
How does it actually work?: An MCP server publishes a list of tools it offers. The AI asks for that list, then asks the server to run one of the tools with specific inputs, and gets structured data back.
A little deeper (optional): The server describes each tool with a name and an input schema, handles authentication itself, and returns structured results the model can read.
Why does this exist?: Every AI product used to need custom integration code for every tool. MCP exists so one server can be reused by many AI clients.
Why did it matter to my project?: Because the constraints of your tools quietly become the constraints of your product.
Where I used it: Used throughout Plugins, Skills & Agents lab, especially while getting the first working screens in front of people.
Common beginner misunderstanding: People think MCP is an AI model or an app. It is a protocol: a set of rules for how AI clients and tool servers talk.
What this tool cannot do: It cannot bypass a service's own permissions, and it does not make the model smarter — it only gives it reach.
What surprised me: How much of the design pressure came from the tool rather than from the problem.

What happens behind the scenes

What the AI is doing

Chooses which tool to call and with what inputs, then explains the result.

What the tool is doing

Defines the tools, checks permissions, performs the action against the real system and returns structured data.

What I am doing

Installs and authorises the server, and approves what it is allowed to do.

What data is moving where?

1.Me → AI: I ask for something
2.AI → MCP server: calls a tool
3.MCP server → service: performs the permitted action
4.Service → MCP server → AI: structured result
5.AI → Me: explanation

What is happening right now?

Deepthi writes an instruction

AI model decides a tool is required

MCP server checks permission

Server performs the action

Server returns structured data

AI explains the result

One thing to remember

Remember this

Choose tools by what they make cheap to change, not by what they make possible.

Try it yourself

Rebuild one screen of your own project with MCP and time it honestly.

Accuracy note: product behaviour checked on 2026-08-15. General concepts are stable; product-specific behaviour can change.

Track 2 · Learn with Deepthi

Connectors

EXPLORED — I researched or discussed it

What did I just discover?: That Connectors was doing more of the work in this build than I gave it credit for.
What I thought it meant: I assumed it was a technical detail I could pick up later.
What I learned: It shaped what was easy and what was expensive, and therefore what the product became.
What is it, really?: A connector is a ready-made link between your AI assistant and an app you already use, so it can read from and act in that app.
Think of it like this (analogy): A workshop tool: it does not decide what you make, but it strongly influences what you find yourself making.
How does it actually work?: You sign in once. The connector holds that permission and exposes a set of actions the assistant is allowed to perform on your behalf.
A little deeper (optional): Behind it usually sits an MCP server or API client that maps assistant tool calls onto the service's real API, carrying your access token.
Why does this exist?: Signing in to each service and wiring up its API by hand is slow. Connectors exist to package that sign-in and those actions once.
Why did it matter to my project?: Because the constraints of your tools quietly become the constraints of your product.
Where I used it: Used throughout Plugins, Skills & Agents lab, especially while getting the first working screens in front of people.
Common beginner misunderstanding: People assume connecting an app gives the AI access to everything in it. Access is scoped to what you approved.
What this tool cannot do: It can only do what the permissions you granted allow, and it inherits that service's own limits and rate limits.
What surprised me: How much of the design pressure came from the tool rather than from the problem.

What happens behind the scenes

What the AI is doing

Decides which connector action fits the request.

What the tool is doing

Holds the authenticated session and performs the action inside the external service.

What I am doing

Signs in, grants scope, and approves or declines what the assistant does.

What data is moving where?

1.Me: sign in and grant permission
2.AI: requests an action
3.Connector: performs it in the service
4.Result: returns to the AI, then to me

What is happening right now?

Deepthi authorises the connector

AI requests an action

Connector applies my permissions

Service performs it

Result flows back to me

One thing to remember

Remember this

Choose tools by what they make cheap to change, not by what they make possible.

Try it yourself

Rebuild one screen of your own project with Connectors and time it honestly.

Accuracy note: product behaviour checked on 2026-08-15. General concepts are stable; product-specific behaviour can change.

Learning checkpoint

Before this chapter

I had screens in my head and a stack I had not yet justified.

After this chapter

A working product, and a much shorter list of things I believed without evidence.

What changed my mind

The stack became a means, not an identity.

Can you answer these?

?Could you rebuild your first screen in an afternoon if you had to?
?Which tool are you using out of habit rather than fit?

Chapter 04

What broke

Track 1 · My journey

A plugin installed but never fired. I had described the tool by name instead of asking for the result I wanted. The moment I asked for the outcome, it ran. Breakage is the most useful part of the process because it is unambiguous. A feature nobody uses is a feature that failed, no matter how well it is built. So I cut, simplified, and made the default path shorter until the product stopped resisting the person using it. I keep this chapter in every book deliberately. The polished version of a build story is not useful to anyone; the failure is where the transferable lesson lives.

Learning checkpoint

Before this chapter

Something that worked in the demo and failed in real life.

After this chapter

A smaller, blunter, considerably more useful product.

What changed my mind

I stopped defending the first version and started measuring it.

Can you answer these?

?What in your build is complete but unused?
?What would you cut if you had to halve the time it takes to use?

Chapter 05

What actually changed

Track 1 · My journey

The point of Plugins, Skills & Agents lab was never the software. It was the change in behaviour around it: fewer things forgotten, less guessing, a clearer handover between the people involved. Working out what plugins, connectors and MCP actually are What I watch for now is whether the thing gets opened a second time, without being asked. Second use is the only honest metric I have found at this scale. Everything else is a story I tell myself. The status of this build: in_progress. That is stated plainly on purpose — unfinished work teaches as much as shipped work, and pretending otherwise makes these books useless.

Learning checkpoint

Before this chapter

A product that worked, and no clear evidence that it mattered.

After this chapter

A clear-eyed view of what the product does and does not fix.

What changed my mind

Success stopped meaning "it is built" and started meaning "it is used".

Can you answer these?

?What behaviour changed because your product exists?
?Would anyone notice if it disappeared tomorrow?

Chapter 06

What I would tell you before you start

Track 1 · My journey

Ask for outcomes, not tools. Trust nothing you have not installed and watched behave. Three things I would repeat on the next build: 1. Describe the problem before naming a tool. The tool is the last decision, not the first. 2. Get something usable in front of a real person within a day. Opinions about a screenshot are worth more than opinions about a plan. 3. Keep a record of the conversation. The transcript is the design history, the documentation and — as this book proves — the product. If you take one thing from Plugins, Skills & Agents lab: the difference between an idea and a product is a short loop, run honestly, many times.

Learning checkpoint

Before this chapter

You have read what happened. Here is what to take with you.

After this chapter

A method you can reuse on a completely different problem.

What changed my mind

The build became repeatable rather than lucky.

Can you answer these?

?What is your version of the short loop?
?What will you ship this week, even if it is embarrassing?

Appendix

Deepthi's Dictionary

Short loop: Describe, build, use, correct — repeated in hours rather than weeks. The core working method behind this build.
Second use: Whether someone opens the product a second time without being asked. The simplest honest measure of whether it works.
Conversation beat: A single line in a build conversation that changed a decision. Collected, these form the real design document.
Worst day design: Designing for the tired, rushed, distracted user rather than the ideal one in a demo.
ChatGPT: ChatGPT — part of the stack used to build Plugins, Skills & Agents lab.
Codex: Codex — part of the stack used to build Plugins, Skills & Agents lab.
MCP: MCP — part of the stack used to build Plugins, Skills & Agents lab.
Connectors: Connectors — part of the stack used to build Plugins, Skills & Agents lab.