WorkMesh has 40 tools with basic schemas and descriptions, but significant quality gaps prevent higher scores. Most tools have descriptions (10-100 chars, below the 50-200 char baseline for LLM optimization) and input schemas with type info, but lack depth. Parameter descriptions are minimal or generic ('Task ID', 'Filter criteria'). No output schemas documented. Error handling is absent, tools return raw results without recovery guidance. Naming is mostly verb-noun compliant, but some tools like 'truth_propose', 'truth_accept', 'truth_reject' are domain-specific and lack clarity for general agents. The 'update_task' and 'update_task_field_or_section' pattern suggests composition issues. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in metadata.

• Add output schemas to every tool. Document field names, types, and structure. Example: 'Returns {id: string, title: string, status: enum, created_at: ISO8601}'. This enables LLM chaining.
• Expand parameter descriptions to 50-150 chars. Include format, constraints, and examples. E.g. 'Filter criteria (JSON object with keys: status, priority, assignee; e.g. {"status": "open", "priority": "high"})'.
• Add error handling with recovery hints. E.g. 'Task not found. Try list_tasks() to find the correct ID.' or 'Invalid status: must be one of: open, in_progress, done, archived.'
• Expose tool annotations in schema. Add readOnlyHint: true for READ_ONLY tools, destructiveHint: true for WRITE/REVERSIBLE tools. Agents will respect safety constraints.
• Clarify domain-specific tools with context. E.g. 'truth_propose: Propose a fact about the project (e.g., "Feature X depends on Feature Y"). Use when establishing shared understanding.' Add examples.