Both tools have minimal descriptions (under 100 chars) and lack comprehensive parameter documentation. Input schemas are present but sparse: 'name' and 'return_value'/'params' lack type constraints, ranges, or validation guidance. No output schema is documented. Error handling is minimal ('Mock not found' is not actionable). The tool names are verb-based (create_mock, invoke_mock) but descriptions do not explain WHEN to use each tool or what prerequisites exist. No mention of idempotency, side effects, or state management. Schemas lack enums, patterns, or constraints that would guide LLM input generation.

• Add formal output schemas for both tools. E.g., create_mock returns {status: string, name: string, mock_id: string}; invoke_mock returns {result: any, call_count: integer, call_history: array}.
• Expand descriptions to 80-150 chars with WHEN/WHY context. E.g., 'Create a mock function with a specified name and return value. Use this to set up test doubles before calling invoke_mock. Mocks are stored in the sandbox and persist across invocations.'
• Add parameter constraints: 'name' should be a non-empty string (1-64 chars, alphanumeric + underscore); 'return_value' should document accepted types (primitives, objects, null); 'params' should be a JSON object with no size limit stated.
• Implement actionable error messages. When mock not found, return available mock names. When invoke_mock fails, suggest create_mock. Include the invalid name in the error response.
• Document idempotency and state behavior. Clarify: does create_mock with duplicate name overwrite or error? Are mocks persistent across tool calls? Can mocks be deleted?