How it works
A tool gives the model a structured way to interact with something beyond the conversation. It usually has a name, a description, input parameters and an expected result. For example, a tool called buscar_pedido can receive an identifier and return the status of a purchase.
The model does not need to know the internal implementation. The host application interprets the call, forwards the parameters to the responsible system and returns the result to the model. In the documentation for the official SDK for the Model Context Protocol, tools are operations called by the model, while resources provide data to the context and prompts are instruction templates chosen by the user.
A tool can only read information, such as checking a forecast, or change the world, such as sending a message, updating a record or starting a purchase. For that reason, the application must validate arguments, limit permissions and ask for confirmation for sensitive actions. The tool description helps the model decide when to call it, but it does not replace security controls on the server.
Practical example
Imagine a customer support assistant for an online store. A person asks where their order is. The agent calls consultar_entrega with the order number, receives the carrier forecast and explains the result in simple language.
If the person asks to change the address, the system can call another tool, solicitar_alteracao_de_endereco. Since this action modifies an order, the flow can ask for confirmation and verify identity before executing it. The agent should not treat a query response as if the change had already been made.
In a software project, similar tools can read files, run tests or open a change request. The tool response is evidence of what happened; the model can use it to decide the next step, but it needs to check for errors and incomplete results.
What it's for
Tools connect an agent to APIs, databases, internal services and authorized commands. This allows AI to move from explaining a task to performing it, without embedding all integrations in the model itself.
A tool should have a small and clear scope. A specific operation, such as listar_faturas, is easier to control than a generic function with unrestricted access to the database. Log who made the call, which data was accessed and whether there was a change. Separate read and write permissions, protect credentials and treat external inputs as untrusted.
A tool is not necessarily intelligent: in general, it is a conventional function or service. AI chooses when to use it and interprets the response; the operation logic continues to be executed by the connected software. This separation makes it easier to swap the model without rewriting each integration and also makes it explicit where to apply validations, limits and human approvals.