{
  "id": 17753387,
  "title": "Day 13/90: Define What Your AI Tools Can Accept—and What They Must Return",
  "url": "https://urgent.news/2026/11/02/day-13-90-define-what-your-ai-tools-can-accept-and-what-they-must",
  "topic": "ai",
  "section": "AI",
  "published": "2026-11-02T05:44:10.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/rimsha_kanwal/day-1390-define-what-your-ai-tools-can-accept-and-what-they-must-return-4gbn"
  },
  "original_language": "en",
  "account": "Day 13 of the 90-day experiment highlights the importance of clearly defining the input and output requirements for AI tools. The Berkeley Function Calling Leaderboard (BFCL) provides a framework for evaluating whether models can correctly call functions across different settings. However, simply making a correct function call is not enough - the actual arguments supplied and the execution of the allowed action must also be evaluated.\n\nOne practical approach is to use JSON Schema to define the input contract for a tool, such as a document search tool. This would specify requirements like a query containing non-whitespace characters, an integer result limit between 1 and 10, and no unexpected fields. The schema helps ensure that the tool receives the expected arguments.\n\nWhen it comes to converting input arguments, there are different approaches. For an integer limit, rejecting the string and returning a specific error might be preferable to coercing the value to an integer. Validation policies should be chosen deliberately and tested thoroughly.\n\nThe output of a tool should also have a defined contract. For a successful search, the response could include a status indicating success, along with an array of results containing document IDs and text. Using a standard output schema, such as that provided by the Model Context Protocol (MCP), allows downstream code to predictably work with the structured results.\n\nIt's important to differentiate between empty results and tool failures. A response indicating success with an empty results array is distinct from an error status. This helps in deciding whether to report missing evidence, retry the operation, or explain a temporary failure to the user.\n\nLastly, permissions should be validated separately from input validation. A well-formed request does not guarantee that the user has the necessary access to the requested data. Both the argument contract and the caller's permissions need to be checked.\n\nImplementing these schema-based approaches can help ensure that AI tools behave consistently and predictably. The next step would be to record the observed behavior of different tool interactions, such as accepted and rejected payloads, malformed outputs, empty results, and tool failures.",
  "summary": "Day 13/90: Define What Your AI Tools Can Accept—and What They Must Return An LLM chooses a search tool and sends this: { \"query\" : \"What is our refund policy?\" , \"limit\" : \"a few\" } The request is understandable to a person. The backend still needs an integer. Should it guess what “a few” means? Use a default? Return an error? This is where tool contracts become useful. While exploring this…",
  "key_points": [
    "Define input contract for tools using JSON Schema",
    "Specify query, result limit, and field restrictions",
    "Test validation policies thoroughly"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}