13 tools with complete JSON schemas and basic descriptions. Naming follows verb_noun convention (drawing, place_edit, thing_edit, etc.). However, descriptions are uniformly terse (10-30 chars), well below the 50-200 char LLM-optimized baseline. Parameter descriptions are almost entirely absent, most params lack any explanation of purpose, format, or constraints. Output schemas are not documented. Error handling and recovery guidance are missing. The 'browse' tool has a complex schema with 16+ optional parameters but no descriptions for any of them, making it difficult for LLMs to reason about valid combinations. Overall structure is sound but lacks the depth needed for confident agent reasoning.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs. similar tools), and WHAT it returns. Example: 'Read a drawing' → 'Retrieve a drawing by type and ID. Use this to inspect visual assets before editing a thing or kind. Returns drawing metadata and image URL.'
• Add descriptions to every parameter. For 'browse', document each enum value and which parameters are valid together. For 'place_edit', explain minLength/maxLength constraints and when each optional field applies.
• Document output schemas for all tools. Specify field names, types, and which fields are safe to pass to downstream tools. Example: 'Returns {drawing_id: integer, url: string, variant_name: string}'.
• Add error handling guidance to write tools (place_edit, thing_edit, buy_credit, flag, say). Specify which errors are retryable, which require user input, and what the LLM should do next.
• For 'buy_credit', clarify the 'request_id' parameter: is it a UUID, a user-generated string, or a transaction ID? Document the retry semantics and what happens if the same request_id is submitted twice.