A tool is an interface to retrieve information or perform an action: find documents, read records, calculate totals or save changes. Models may propose usage, but services execute and enforce permissions. Tool access does not mean access to every resource.
APIs exchange structured requests and responses. Connectors bring these capabilities into applications. MCP exposes tools and resources to compatible clients; it does not guarantee accuracy, permissions or integration quality. Business users need to know available operations and verification.
Retrieve relevant information
Retrieval supplies documents to a model; combined with generation it is often called RAG. It does not train the model on those files or guarantee retrieval of the right passage.
Check document identity, version, context and permissions. A discount search might retrieve an obsolete policy or another customer's exception. Preserve evidence sufficient to assess relevance.
Operation contracts
Specify inputs, outputs, permissions and errors. Reading needs exact IDs, scope and update time. Writing needs object identity, proposed changes, preconditions and confirmation. Handle nonexistent objects and changes made since reading.
Avoid ambiguous requests such as updating an important customer. Resolve identity before writing; similar names require identifiers rather than guesses.
Partially failed writes
A timed-out operation may have succeeded. Check state before retrying. Supported idempotency mechanisms identify attempts of one action and reduce duplication. Asking a model to remember is not equivalent.
Test reading first and changes in a controlled environment. Technical owners implement controls; process owners define valid updates. Both need evidence of success, failure and recovery.
Worked case
Andina Equipos has two customers named Transporte Norte. A name-only tool updates the wrong contact: identity was the initial failure. Require ID, record reading and confirmation of the proposed change.
If saving times out, query state to check whether the update exists. Retry only when evidence supports avoiding duplication or overwriting later changes.
Practice instructions
Resolve the object by ID and read state before proposing a write.
Show current field, requested change and authorization source.
Verify confirmation afterward and reread when necessary.
Stop retries when outcomes remain ambiguous.
Your turn
Define contracts for reading an opportunity and recording a next action. Include required data, permissions, errors and ambiguous-response handling.
Show the commented solution
Reading uses an ID and returns state, version and source. Writing needs opportunity ID, unique action ID, content, owner, authorization and expected version where supported. The service validates permission and returns confirmation. Query the action ID before creating another after an ambiguous outcome.