Why an AI agent that cannot touch your tools is just a chatbot

A language model only generates text. To do real work, an agent must connect to the software where business data lives: help desks, CRMs, databases and internal APIs. Model Context Protocol (MCP) and scoped connectors give the model tools to read data and take actions, with written guardrails and human approval for anything that changes state.

The chatbot trap

The most common disappointment with AI in a company goes like this. The demo was brilliant. The model answered questions, wrote poems and summarised meeting notes. Then the team tried to use it for real work, like processing an order or handling a ticket, and realised it could not touch any of their software.

Without tools, a model can only give advice. It can draft an email, but cannot send it. It can recommend a refund, but cannot check whether the invoice was paid. It can suggest a schedule, but cannot see who is booked.

The moment you give a model tools to read your database and trigger actions, it stops being a chatbot and becomes an agent. That transition is where most projects fail.

What a tool actually looks like to an AI

A tool is not magic code. To a language model, a tool is simply a structured description written in JSON Schema. It tells the model three things: what the tool is called, what job it does, and what inputs it requires.

• Name: look_up_order.
• Description: Fetches order status, tracking number, items and total given an order ID or email.
• Parameters: order_id (string, optional), customer_email (string, optional).

When a customer asks where their package is, the model does not answer from memory. It outputs a structured tool call. Your server runs the query against your database and sends the result back. The model reads the real result and writes the reply. The model never touches the database directly.

Why Model Context Protocol (MCP) changes the math

Until recently, connecting an agent to five tools meant writing five custom API integrations. Every API had different authentication, error formats and schemas. Maintaining twenty custom connectors across different apps quickly became unsustainable.

Model Context Protocol (MCP), open-sourced by Anthropic and adopted across the industry, created a universal standard. An MCP server exposes tools, resources and prompts in a common protocol over standard input or HTTP. An agent platform like Keel connects to an MCP server once, and instantly gets access to all its verified tools without custom glue code.

Keel comes with pre-built connectors for work management tools like Linear, Jira, Notion and Asana, cloud platforms like GitHub, GitLab and Vercel, and internal databases via Postgres.

The three failure modes of AI tools

Connecting tools is straightforward. Making them reliable in production is where the engineering lies.

1. Tool explosion and token waste. Giving an agent fifty tools in its prompt confuses the model and wastes thousands of tokens per request. An agent needs only the three to five tools relevant to its specific job.
2. Vague descriptions. If a tool description does not clearly state when to call it and when not to, the model will hallucinate inputs or call the wrong endpoint on edge cases.
3. Unbounded write actions. Giving an AI write permissions to a production database or customer inbox without a human review gate guarantees an expensive accident.

The difference between read tools and write tools

At Infrenic, we enforce a strict separation in Keel between two classes of tools.

• Read tools: Searching documents, querying order status, checking calendar slots, reading ticket history. These are safe, idempotent and run automatically without human intervention.
• Write tools: Sending an email to a customer, issuing a refund, modifying a database record, opening a production ticket. These carry real-world consequences and require a human approval step until accuracy is proven across hundreds of real cases.

This rule alone prevents 99 percent of the horror stories companies worry about when adopting AI.

How we build it on Keel

Every agent we deploy for clients runs on Keel. Connectors are defined once and scoped with granular permissions. An agent for customer support gets read access to your knowledge base and order table, but its action to issue refunds requires an approval gate in our staff portal.

See our production AI agent checklist. The ten requirements an agent must meet before handling real customer work.

Send us a workflow to automate. A working prototype on your data and tools in 48 hours, free.

FAQ

Infrenic builds AI agents on your data and tools, ships them to production and runs them, all on Keel. Send us a problem and see it working in 48 hours.