Useful AI needs good tools and clear boundaries

What interests me about AI is whether it helps with a concrete task. Summarising a document, finding information, preparing a draft or shortening a tedious step: I see plenty of useful applications.

Once a model works with real data and applications, another question becomes important. Which tools does it get, and what may happen through them?

Function calling and MCP make this a practical development question. The documentation available in September 2026 shows how models can connect to custom functions and external services. For me, much of the engineering work lies in designing those connections.

A tool should have an understandable purpose

OpenAI describes functions through names, descriptions and argument schemas. Strict mode can enforce adherence to those schemas. Its function calling documentation explains the requirements.

For a project assistant, I would provide three focused tools: search tasks, read a task and prepare a proposed change. A universal tool that executes arbitrary database queries would be unnecessarily difficult to control for this purpose.

Anthropic also connects interface design with evaluation in its article on writing tools for agents. My takeaway is to design each tool around the task it serves.

prepareTaskUpdate already communicates something about the intended operation. To me, that contract also includes clear errors, bounded results and stable identifiers. A model should not have to guess whether “Project Miller” means the current engagement or one that ended years ago.

Reading, preparing and executing

MCP provides a shared interface for tools. In the Responses API, developers can limit the available MCP tools and require approval for calls. OpenAI documents options including allowed_tools and require_approval in its MCP guide.

For my example application, I would make three steps visible:

1. The assistant reads the tasks it is allowed to access.
2. It presents a specific proposed change.
3. After the required approval, the backend executes that exact change.

The approval should identify the record and its proposed values. A generic “May I continue?” gives me little to assess. If the proposal changes afterwards, the earlier confirmation should not automatically authorise the new version.

I would decide which steps can run without a question according to their actual risk. Even reading can transfer confidential information to an external service. Preparing a local draft, meanwhile, does not need the same process as sending a message.

External text does not gain extra permissions

An email being read can contain instructions. That does not give it permission to export other data. OpenAI describes this kind of prompt injection in its agent safety guidance.

My response would be a technical separation: Content supplies information, while the server checks identity, workspace membership and permitted operations. A correctly shaped JSON object does not prove either authorisation or a sensible decision.

I would also store a unique identifier for each approved write operation. If the same execution arrives again, the backend can return the existing result. A retry should not quietly become a second task or a duplicate message.

I want to test the workflow

An impressive demonstration is not enough for me to judge a feature. OpenAI's evaluation recommendations cover ordinary tasks, edge cases and adversarial inputs.

For my task assistant, I would collect a small set of specific cases: two projects with the same name, missing membership, a record that has changed in the meantime, a duplicate execution and a task description containing injected instructions.

I would check whether the assistant selects the right task, asks when the request is ambiguous and changes data only at the intended step. I would also observe duration, failed attempts and cost per completed task. The same cases should run again whenever a model, prompt or tool changes.

These are the questions that make AI interesting to me as a developer. A useful product emerges when the model, its tools and the application form a dependable workflow together. That is how I would judge its quality.