Chapter 8: Tools, MCP, A2A, and Integration Plumbing
We have now given our model:
- somewhere to run
- a harness
- context
- memory
- retrieval
- perhaps a router deciding which model gets the job
Excellent.
Eventually somebody is going to say: (or poke it with a stick)
“Okay. Do something.”
And this is where the architecture stops being theoretical.
The model cannot physically turn on a light.
It cannot query Home Assistant history.
It cannot add milk to a shopping list.
It cannot search your documents.
It cannot fix your YAML.
Something has to provide those capabilities.
Those things are generally called:
tools
What Is a Tool?
A tool is a capability the harness makes available to the model.
Conceptually:
USER
│
▼
MODEL
│
│ chooses capability
▼
TOOL
│
▼
SYSTEM
For Home Assistant:
USER
│
▼
MODEL
│
▼
turn_on_light
│
▼
HOME ASSISTANT
The model does not directly operate the light.
It asks the harness to invoke a capability.
That distinction matters.
Tools Are Interfaces
A good tool hides implementation detail.
The model should not need to understand:
HTTP endpoint
authentication header
database schema
service implementation
Python library
device protocol
to turn on a light.
It should understand something closer to:
turn_on_light
or:
get_room_detail
or:
search_household_knowledge
That is abstraction again.
The implementation underneath can change while the capability presented to the agent remains stable.
Tools Can Read and Act
Some tools retrieve information:
get_room_detail
search_household_index
get_energy_history
Others change something:
turn_on_light
create_task
start_vacuum
A read tool gets information into context. An action tool changes the world.
Those deserve different thought once permissions and security enter the picture.
The Tool Is the Bridge
Remember Chapter 7.
Suppose your recipe system contains exactly the information the model needs.
Without a useful path:
RECIPE SYSTEM
X
HARNESS
The recipe exists.
The agent still cannot use it.
Add a tool:
RECIPE SYSTEM
│
▼
RECIPE TOOL
│
▼
HARNESS
│
▼
MODEL
Now that system exists inside the agent’s working world.
This is why tools matter so much.
It Will Only Do What You Give It
This is one of the less glamorous truths about agentic AI.
Home Assistant gives us a very capable foundation: state, entities, service and intent infrastructure, an LLM API, and extension points for additional capabilities.
After that, the ceiling depends heavily on what somebody actually builds or connects.
Want the agent to search household knowledge?
Give it a search tool.
Want it to manage maintenance?
Give it a maintenance tool.
Want it to coordinate inventory?
Give it an inventory tool.
Want it to use a software-development agent?
Give it a safe path to one.
Want it to coordinate lights, music, an ESP32, and Uncle Joe’s whoopie cushion?
Apparently that is also your problem now.
The model supplies reasoning.
Tools define what that reasoning can actually reach.
Home Assistant Gives You the Foundation
Home Assistant already exposes useful capabilities to LLM conversation agents through its LLM APIs.
The built-in Assist API works through Home Assistant intents and exposed entities instead of requiring every model integration to reinvent home control.
Integrations can also contribute additional tools.
Conceptually:
HOME ASSISTANT
│
▼
LLM API
│
┌───────┴───────┐
▼ ▼
ASSIST TOOLS CUSTOM TOOLS
│ │
└───────┬───────┘
▼
HARNESS
│
▼
MODEL
That is already an agent tool architecture. What you build on top can be as small or ridiculous as you care to make it.
Home Assistant Is Making the Tool Surface More Semantic
This is not a static area.
Home Assistant has been improving its intent and LLM-facing surfaces so agents can ask for useful current state more naturally.
Instead of exposing piles of entity-specific getters:
get_light_1_state
get_light_2_state
get_temperature_1
get_temperature_2
get_sensor_847
you want something more like:
get/check state
│
▼
name / area / floor / type
│
▼
live HA state
Recent changes around the HA state intent have made this sort of current-state lookup considerably friendlier to an agent.
Better semantic tools mean fewer tools, less schema, less context, and concepts shaped more like the way humans actually think about the house.
A Good Tool Is Shaped for the Job
Imagine exposing:
execute_sql(query)
Technically powerful.
Also a lot to hand a household conversation model.
Compare that with:
find_recipes(ingredients)
or:
get_device_maintenance(device)
or:
search_household_index(query)
The second group expresses useful concepts, gives the model less implementation detail to understand, and gives the tool more opportunity to validate and constrain the request.
Tool Schemas Matter
The model needs to know how to call a tool.
A tool generally describes things such as:
- its name
- what it does
- its arguments
- argument types
- required fields
Conceptually:
TOOL:
get_room_detail
DESCRIPTION:
Return detailed state and household context for one room.
ARGUMENTS:
room_name: string
That description becomes part of the model’s working material.
And now we hit a practical problem.
Too Many Tools Are a Real Problem
Suppose you expose 300 tools.
Your architecture may not merely become confusing.
Depending on the provider, the request may fail outright.
OpenAI-style function calling currently limits a request to 128 active function tools.
Even before you hit it, every tool consumes model attention and context.
The model needs enough information to understand:
tool name
description
arguments
argument descriptions
schema
All of that has to fit somewhere.
Tool Descriptions Have Practical Limits Too
There is another useful observed limit.
In independent testing against the MCP/tool surface, tool descriptions were accepted through 2048 characters and began dropping content at character 2049.
Treat that as observed implementation behavior rather than a permanent protocol guarantee. It may change.
But the more important question is:
Do you really want a 2,048-character description on every tool?
Imagine:
100 tools
×
~2,000 characters of description
+
argument schemas
and we still have not included:
system prompt
home context
conversation
retrieved knowledge
user request
Congratulations.
Your tool catalog ate lunch before the user got to speak.
Tool Context Is Still Context
This is the Chapter 7 lesson again.
Context is finite.
Tool count is finite.
Tool descriptions consume context too.
So:
Tool count is finite. Tool-description budget is finite. Context is finite. Spend all three on useful abstractions.
A tool description should be long enough to remove ambiguity.
It should not be a novella.
Nobody wants the model reading War and Peace before it can turn on a lamp.
Tool Discovery Starts to Matter
Once a system has a large capability catalog, a healthier architecture begins to look like:
FULL CAPABILITY CATALOG
│
▼
FIND RELEVANT TOOLS
│
▼
SMALL ACTIVE TOOL SET
│
▼
MODEL
This is basically retrieval again.
The model should see the capabilities relevant to the job.
It does not necessarily need every capability the system has ever heard of.
One Real Example of Tool Shaping
If you want to see what this looks like when somebody takes the idea a little too far, I have conveniently done that for you.
In ZenOS, Taskmaster presents household task management as one agent-facing capability.
Behind it may be several systems.
The tool can use Microsoft To Do for baseline tasks, a service-desk backend when available, or inventory/chore systems when that task shape fits.
The agent does not need separate mental models for every backend.
Conceptually:
TASKMASTER
│
┌──────────────┼──────────────┐
▼ ▼ ▼
TO DO SERVICE DESK INVENTORY
The backends keep their own native data models.
The agent gets one task-oriented capability.
Source:
That is the design pattern: one meaningful tool, several implementation paths, while the backends keep their native data models.
Another Example: Give the Model a Room, Not 200 Sensors
The same idea applies to Home Assistant state.
A model could inspect every sensor associated with a room.
Or we can expose something like:
get_room_detail("living_room")
and return a useful room-level representation.
ZenOS Room Manager does this by combining room topology, live state, occupancy, inventory, chores, tasks, calendar information, and other context behind a room-oriented tool.
Source:
Conceptually:
RAW HA INFORMATION
│
├── topology
├── state
├── occupancy
├── inventory
├── tasks
└── related context
│
▼
ROOM TOOL
│
▼
USEFUL ROOM BRIEF
Same philosophy: do not make the model reconstruct a useful concept from fifty primitives if the harness can provide it directly.
You Can Take This As Far As You Want
Once you understand tools, supposedly futuristic behavior becomes much less mysterious.
Want a household agent that manages:
rooms
maintenance
inventory
documents
tasks
media
calendar
Those are capabilities.
Want a codebot?
That may look like:
HOUSEHOLD HARNESS
│
▼
DEVELOPER AGENT
│
▼
REPOSITORY
│
▼
TEST / PATCH / REPORT
Want it to control infrastructure?
Give it an appropriately scoped infrastructure tool.
Want it to reason over household finance?
Give it the appropriate data and tools.
The agent only has the abilities somebody actually implements and exposes.
AI does not remove integration engineering. It makes it enormously more powerful.
Capability Classes Become Useful
Once a system gets large, it helps to decide whether every callable thing belongs on the agent-facing surface.
For example:
AGENT-FACING TOOL
│
▼
INTERNAL SERVICE
│
▼
LOW-LEVEL API
The model may only need the first layer, keeping internal transport, administrative functions, and implementation mess out of the tool catalog.
I eventually wrote down a taxonomy for this in ZenOS because the difference began to matter.
Source:
The useful part is simple:
Two things can both be Home Assistant scripts while having completely different architectural jobs.
An agent-facing semantic capability and a low-level transport primitive should not automatically be exposed the same way.
You do not need my taxonomy.
You do need to decide what belongs on your model-facing tool surface.
APIs Are Still Fine
A tool does not require an exotic agent protocol underneath it.
The implementation might use:
REST
WebSockets
GraphQL
MQTT
Python
Home Assistant services
SQL
If you already have an excellent API integration:
use it.
The model cares about the capability presented by the harness.
It does not particularly care what plumbing happens underneath.
So What Problem Does MCP Solve?
Now imagine somebody has written a useful service.
Perhaps it can:
search documents
use a browser
query a calendar
access a repository
operate another application
And several different AI harnesses want those capabilities.
Historically, every pair could require its own connector.
HARNESS A → CUSTOM CONNECTOR → SERVICE
HARNESS B → DIFFERENT CONNECTOR → SERVICE
HARNESS C → ANOTHER CONNECTOR → SERVICE
That gets tedious.
Enter MCP.
MCP
MCP stands for:
Model Context Protocol
At the lighthouse level, think of MCP as:
a standardized way for AI applications to discover and use external capabilities and information
Conceptually:
AI HARNESS
│
▼
MCP CLIENT
│
▼
MCP SERVER
│
▼
CAPABILITY
The protocol is evolving rapidly, so use current documentation when actually building against it. We care here about the architectural idea.
MCP Is Plumbing
Think of USB.
USB does not define what a keyboard should type.
It provides a standard way for devices and computers to communicate.
MCP has a similar role in AI systems.
An MCP server might expose:
web search
document retrieval
calendar access
Git operations
Home Assistant capabilities
An MCP-capable harness can discover those capabilities and make them available to the model.
Home Assistant Can Consume MCP Tools
Home Assistant can act as an MCP client.
That means an external MCP server can provide capabilities to a Home Assistant conversation agent.
Conceptually:
EXTERNAL MCP SERVER
│
▼
HOME ASSISTANT
MCP CLIENT
│
▼
CONVERSATION AGENT
Maybe that external server provides:
web search
document search
specialized service
Now those capabilities can become part of the Home Assistant agent’s working world.
Home Assistant Can Also Expose Capabilities Through MCP
The arrow can go the other direction too.
Home Assistant can act as an MCP server so an external MCP-capable agent can use Home Assistant capabilities.
EXTERNAL AGENT
│
▼
MCP CLIENT
│
▼
HOME ASSISTANT
MCP SERVER
│
▼
HOME
That is a very different architecture.
In one case, Home Assistant is the primary harness gaining external tools.
In the other, an external harness is gaining Home Assistant as a capability.
Remember Chapter 3:
Find the harness.
That tells you which working world is primary.
MCP Does Not Invent Tools
If an MCP server exposes:
list_inventory
but not:
move_inventory
MCP does not magically create the second one.
It standardizes access to what somebody implemented.
Likewise:
“Supports MCP”
does not mean:
“Has every capability I need.”
Inspect the actual tools.
And read their documentation.
MCP Tools Are Someone Else’s Interface
There is a practical difference between using an MCP tool somebody else wrote and building your own.
With a DIY tool, you decide what the agent needs to know, what it can do, what information comes back, and what limits surround the capability.
With a third-party MCP server, you are using the capability surface its author designed.
You are partly at the mercy of what that author thought your agent should:
be able to read
be able to change
know about the system
receive as context
do when something fails
confirm before acting
The tool may expose exactly what you need, much more, or less. It may also make sensible assumptions for the author’s environment that are wrong for yours.
So before giving an MCP server to an agent:
Read the tool documentation.
Understand:
what tools are exposed
what each tool can actually do
what credentials it uses
what data it can read
what it can change
what confirmations it expects
what limits it assumes
what errors it returns
Pay attention to cautions from the author.
If the documentation says:
do not call concurrently
or:
this operation can delete resources
or:
confirmation is required before this action
those are part of the integration contract.
Your model does not magically know those requirements unless the harness, tool description, or surrounding controls communicate them.
MCP or DIY Tool?
Neither is automatically better.
A good MCP server can save an enormous amount of integration work.
A purpose-built tool gives you control over exactly what the agent sees.
Roughly:
THIRD-PARTY MCP TOOL
│
├── faster integration
├── standardized plumbing
└── author defines capability surface
versus:
DIY TOOL
│
├── more work
├── exact capability shape
└── you define behavior and limits
For a low-risk information service, an existing MCP server may be an easy choice.
For something that can materially change your home, infrastructure, finances, or security posture, inspect that tool surface very carefully before giving it to an autonomous agent.
Convenient plumbing does not remove the need to understand what is on the other end of the pipe.
MCP Is Not Permission
Giving something an MCP interface answers:
“Can these systems communicate?”
It does not automatically answer:
“Should this caller be allowed to perform this action?”
Suppose a tool exists:
unlock_front_door
There are several different questions:
Does the tool exist?
Can this harness see it?
Can this user invoke it?
Can this identity operate this lock?
Should confirmation be required?
Those are not the same question.
Reachability Is Not Authorization
A mature path may look more like:
MODEL
│
▼
TOOL REQUEST
│
▼
IDENTITY / POLICY
│
├── DENIED
│
└── ALLOWED
│
▼
ACTION
MCP can be part of the communication path.
Authorization remains an architectural responsibility.
We will deal with that properly in Chapter 10.
Instructions Are Still Not Controls
A prompt saying:
“Please never unlock the front door for guests.”
is an instruction.
A policy layer saying:
guest
│
▼
unlock_front_door
│
▼
DENIED
is a control.
We covered that in Chapter 3.
Now you can see where it lands in the actual plumbing.
Tool Scope Matters
Compare:
home_assistant_api_call(method, path, body)
with:
get_room_state(room)
or:
control_exposed_device(entity, action)
The first gives the agent a very broad surface.
The others expose narrower capabilities.
Broad administrative tools may be appropriate for a highly trusted developer agent.
A household conversation agent may deserve something much narrower.
The model may be identical.
The tool surface changes what it can do.
This Is Why a Codebot Is a Different Animal
Suppose you want a coding agent working on Home Assistant configuration.
You can absolutely build that.
Its tool world may include:
filesystem
Git
shell
tests
Home Assistant config
documentation
That agent could potentially:
inspect an automation
modify YAML
run checks
commit changes
Very cool.
It also has a dramatically different capability surface from:
turn_on_light
So when somebody asks:
“Can Home Assistant AI edit my configuration?”
the useful answer is:
It can if you give an agent the tools and authority necessary to do that.
Home Assistant does not need to ship a magical universal codebot for the architecture to be possible.
You can build one.
You also inherit everything that comes with handing an agent those capabilities.
Tool Results Become Context
Suppose the model calls:
get_room_detail("kitchen")
The tool returns:
Kitchen:
occupied
76°F
dishwasher running
window closed
That result becomes new context for the model.
So the loop is:
CONTEXT
│
▼
MODEL
│
▼
TOOL CALL
│
▼
TOOL RESULT
│
▼
NEW CONTEXT
│
▼
MODEL
That is the basic agent loop.
Tools and context are tightly connected.
Retrieval Can Just Be a Tool
Remember our indexed retrieval discussion from Chapter 7?
Conceptually:
HOUSE KNOWLEDGE
│
▼
INDEX
│
▼
search_household_index()
│
▼
HARNESS
The backend might use:
Home Assistant data
SQL
an index
vectors
documents
several systems
The model does not need to understand any of that.
It gets:
search_household_index(query)
That is one reason tool-shaped retrieval is so useful.
It lets the harness ask for information when needed without loading the entire house into context.
MCP Can Expose Retrieval Too
The same retrieval capability could come through MCP:
MODEL
│
▼
search_documents
│
▼
MCP
│
▼
RETRIEVAL SERVICE
Or retrieval could happen automatically inside the conversation integration before the model sees the request.
Remember Skye’s Local OpenAI LLM + Weaviate example from Chapter 7.
These mechanisms are not mutually exclusive.
The useful question remains:
What is the cleanest reliable path from the harness to the information?
So What About A2A?
Now we need another distinction.
MCP primarily helps an AI application interact with tools, resources, and capabilities.
A2A, or Agent2Agent, addresses communication between independent agents.
At the simplest level:
AGENT → TOOL
│
▼
MCP
versus:
AGENT ↔ AGENT
│
▼
A2A
That is simplified, but useful.
Tool or Agent?
Suppose your household agent needs weather information.
That is probably a tool:
HOUSE AGENT
│
▼
WEATHER TOOL
Now suppose it needs a specialist software-development system to:
- inspect a repository
- develop a plan
- modify several files
- run tests
- report back
That begins to look more like:
HOUSE AGENT
│
▼
DEVELOPER AGENT
│
▼
MULTI-STEP WORK
The developer agent has its own:
- context
- reasoning
- tools
- state
- permissions
The caller delegated a goal rather than invoking one operation. That is the distinction.
Do You Need A2A?
Probably not to turn on the kitchen light.
For most Home Assistant systems:
HARNESS
│
├── HA tools
├── retrieval tool
├── external APIs
└── a few MCP tools
can accomplish an enormous amount.
A2A becomes interesting when you genuinely have independent agent systems.
Maybe someday:
HOUSEHOLD AGENT
│
├── DEVELOPMENT AGENT
├── RESEARCH AGENT
└── OTHER SPECIALIST
Each can have its own model, tools, context, and trust boundary.
At that point, standardized delegation between them becomes useful.
Do Not Build a Committee Because You Can
One agent with five good tools may be easier to operate than:
SUPERVISOR AGENT
│
├── LIGHTING AGENT
├── THERMOSTAT AGENT
├── VACUUM AGENT
├── TOASTER AGENT
└── AGENT MANAGEMENT AGENT
Nobody needed a toaster department.
Use a tool when a tool solves the problem.
Use another agent when the problem actually benefits from independent reasoning, context, tools, or lifecycle.
Simple is still better.
Tools Should Fail Clearly
Suppose the model calls:
turn_on_light(light.kitchen)
and receives:
ERROR
Useful.
Very informative.
Compare that with:
FAILED:
entity light.kitchen is unavailable
or:
DENIED:
caller may view but may not control this entity
or:
NOT FOUND:
no exposed entity named light.kitchen
Good errors help the model recover. Bad errors invite guessing.
Tools Should Not Get Creative With Failure
Suppose the model invents:
lock.secret_bunker
Good tool behavior:
NOT FOUND
Less good:
I could not find that lock,
so I operated another lock that seemed bunker-ish.
No.
Invalid or unauthorized requests should fail cleanly.
Creativity is lovely. Control paths should have less of it.
Tools With Side Effects Deserve More Thought
Compare:
get_front_door_state()
with:
unlock_front_door()
Or:
get_account_balance()
with:
send_payment()
The second tool in each pair changes something consequential.
Those tools may deserve:
- stronger identity requirements
- scoped authority
- confirmation
- logging
- limits
We will cover those controls in Chapter 10.
For now:
Reading and acting are different capability classes.
Tools Should Be Observable
If an agent does something, you should ideally be able to answer:
what tool was called?
when?
by whom?
with what arguments?
what happened?
For example:
16:42
caller: household-agent
tool: turn_off_area
target: downstairs
result: success
That becomes especially useful when somebody asks:
“Why the hell did the patio lights just turn off?”
A Practical Progression
For most Home Assistant users, I would approach capabilities roughly like this.
Start With Home Assistant
If HA already exposes what you need through Assist or another LLM API:
use it.
Add Purpose-Built Tools
If another system owns useful information or actions:
give the harness a good tool for it.
Add Retrieval
If the harness needs to search household knowledge:
give it an index or retrieval tool.
Add MCP When It Solves Integration
If you want standardized external capability access:
MCP may be useful.
Add Other Agents When You Actually Need Agents
If a task genuinely benefits from independent reasoning and delegation:
then consider A2A or another delegation mechanism.
You can stop anywhere in that progression.
The Plumbing Should Stay Boring
At this point we have discussed:
- native HA tools
- APIs
- custom LLM APIs
- retrieval tools
- MCP
- external agents
- A2A
It is very easy to respond by constructing:
twelve gateways
three protocol bridges
two agent buses
an MCP mesh
a queue
a service registry
and something called Enterprise Cognitive Fabric
Please remember where we are.
This is a house.
A perfectly capable architecture may still be:
HOME ASSISTANT
│
▼
AGENT
│
├── HA tools
├── index tool
└── one external service
Fantastic.
Stop.
The plumbing exists to give the agent useful capabilities. It does not have to become the hobby.
If You Want to See How Far It Can Go
The examples above come from my own ZenOS project because I wrote this article and have a large HA-native agent system handy to point at.
I am not suggesting you (MUST) install it. 
Use the source as an example of how ordinary Home Assistant primitives can become:
- room intelligence
- task orchestration
- indexed retrieval
- inventory management
- media control
- infrastructure tools
- administrative surfaces
If you want something like that:
knock yourself out.
The important principle is bigger than any one implementation:
Home Assistant gives you the primitives. The capabilities you build determine what your agent becomes.
A Larger Architecture, If You Actually Need One
Eventually you could have:
USER
│
▼
PRIMARY HARNESS
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
HA LLM API RETRIEVAL TOOL MCP CLIENT
│ │ │
▼ ▼ ▼
HOME ASSISTANT HA INDEX MCP SERVICES
│
┌───────┼───────┐
▼ ▼ ▼
WEB DOCS OTHER
│
▼
SPECIALIST AGENT
if needed
That is already a ridiculous amount of capability for a house. No swarm required.
Or Put the Harness Outside
You can reverse the architecture:
EXTERNAL HARNESS
│
├── MCP → HOME ASSISTANT
│
├── MCP → OTHER SERVICES
│
└── A2A → SPECIALIST AGENT
Now Home Assistant is one capability provider inside a larger agent environment. That can work too, but it changes the primary security boundary.
Remember:
The harness defines the working world.
The Questions That Matter
Whenever you add a capability, ask:
- What owns the information or action?
- How does the harness reach it: native tool, API, MCP, or another agent?
- What exactly am I exposing?
- How many tools am I exposing, and what are they costing in context?
- Could several small tools become one better semantic capability?
- If this is somebody else’s tool, have I read the docs and understood its assumptions, cautions, limits, confirmations, and side effects?
- Who can use it?
- What happens when it fails?
- Can I see what happened?
- Does another layer actually help?
Always worth asking.
The Cheat Sheet
At this point we have accumulated enough terminology to cause emotional damage.
So:
API
A programmatic interface to a system.
Tool
A capability shaped for the harness/model to use.
MCP
A standardized way for AI applications to access external capabilities and context.
Agent
A system capable of pursuing a goal using reasoning and tools.
A2A
A way for independent agents to communicate and delegate work.
Harness
The environment that assembles models, context, tools, rules, and execution.
Do not worry about building the One True Diagram.
Build the smallest one that reliably solves your problem.
And Now We Can Finally Talk About Home Assistant
We have spent eight chapters assembling the pieces.
We now have models, harnesses, inference, hardware, routing, context, memory, retrieval, tools, MCP, and agent delegation on the board.
So we can finally point directly at Home Assistant and ask:
What does Home Assistant itself give me today?
We need to look at:
- Conversation Agents
- Assist
- the LLM API
- AI Tasks
- voice pipelines
- current live-state and intent capabilities
- MCP client and server
- built-in provider integrations
- representative community integrations
- inside-out architectures
- outside-in architectures
And then we can answer the question we have been circling since Chapter 1:
Okay, what can I actually build with this stuff?
Next: