Most API documentation is written for humans. MCP tool descriptions are different. They are read by the model that decides what to call next. That means tool names, descriptions, schemas, and error messages are not just documentation garnish. They are part of the safety boundary. A bad tool asks the model to guess A risky MCP tool often looks like this: name: query input: free-form string description: “Run SQL against the database” Technically simple. Operationally vague. The model has to infer when to use it, what is safe, which tables matter, and what failure means. That is not a production boundary. That is a shrug with JSON around it.…