Single tool with adequate naming but critical gaps in description depth, parameter documentation, and output schema specification. Tool name 'compute_stable_matching' is clear and verb-based, but description (145 chars) lacks actionable context for LLM selection. Input parameters have type info but descriptions are generic and lack constraints. No output schema documented. No error handling guidance. Fails multiple critical checks from rubric section D (Schemas & Output) and E (Error Handling).

• Document complete output schema: specify that 'matches_by_proposer' is {proposer_id: acceptor_id}, 'matches_by_acceptor' is {acceptor_id: proposer_id}, and 'is_stable' is boolean. Include example output.
• Add parameter constraints to descriptions: 'proposer_prefs: dict where keys are unique proposer identifiers (strings) and values are ordered lists of acceptor identifiers. All acceptors in preferences must exist in acceptor_prefs. Preference lists must be non-empty and contain no duplicates.'
• Expand tool description to 100-200 chars explaining use case: 'Compute a provably stable bipartite matching between proposers and acceptors using the Gale-Shapley Deferred Acceptance algorithm. Use when assigning workers to tasks, students to schools, or any two-sided matching problem where both sides have strict preferences and no blocking pairs are acceptable.'
• Add error handling documentation: document what happens if preferences are invalid, if proposer/acceptor sets are disjoint, or if the algorithm cannot match all proposers. Return structured error responses with actionable guidance.
• Add parameter type hints to schema: mark proposer_prefs and acceptor_prefs as 'object' with additionalProperties: {type: 'array', items: {type: 'string'}} to enforce structure at schema level.