Start with the official API documentation for the business service and a task your account is permitted to perform. One narrow, well-described tool is easier to test than a generic tool that accepts an arbitrary URL and method.
Define the request#
Give the tool a stable name and a description that explains its purpose, important limits and whether it changes data. Select the documented HTTP method and endpoint. Use placeholders only for the variable path elements the operation actually permits.
For a fictional record lookup, the path might contain a record identifier. The hostname and account region should remain part of the configured connection rather than open-ended model input.
Define and map inputs#
Use the input schema to describe each field, its type, required status and valid values. A small schema for a fictional lookup is:
{
"type": "object",
"properties": {
"record_id": {
"type": "string",
"description": "The verified identifier of the record to read"
}
},
"required": ["record_id"],
"additionalProperties": false
}Map arguments to the documented path, query or body fields. Check that missing required fields and unexpected extra arguments fail clearly. Keep authentication in the supported server connection, not in a prompt, example schema or hard-coded tool header.
Shape the output#
Response mapping or transformation can return the fields the workflow needs instead of an entire service response. Verify the transformed output against the original test result. Do not remove the record identifier, pagination information or error detail needed to understand whether the result is complete.
Review operating settings#
The tool configuration supports timeout, caching and retry settings. Use caching only when stale data is acceptable; a cached read is unsuitable as final proof that a write just completed. Retrying a non-idempotent write can create duplicates, so choose retry behaviour from the API's documented guarantees.
Test the real path#
Check correct input, invalid input, empty results, permission failure and a bounded successful call. Test diagnostics may contain sensitive request information; inspect them only through the approved administrator route and redact before sharing. See testing before a client uses the tool.