Two tools with partial schemas and descriptions. Tool 1 (dynamic_openapi_tool_generation) has a reasonable description (145 chars) and input schema with 4 properties, but lacks output schema documentation and parameter descriptions are minimal. Tool 2 (invoke_generated_tool) has a good description (165 chars) but schema is incomplete: 'arguments' property lacks type definition (just 'object' with no properties), and 'toolName' is required but 'arguments' is not, creating ambiguity. Neither tool has error handling guidance, output schemas, or parameter constraints (enums, ranges). Naming is verb-based but generic ('invoke_generated_tool' could be clearer about what 'generated' means). No evidence of idempotency hints, permission gates, or recovery guidance.

• Add explicit output schema for dynamic_openapi_tool_generation: return array of {name, description, httpMethod, pathTemplate, inputSchema} with full documentation of each field.
• Expand invoke_generated_tool 'arguments' schema: define it as object with additionalProperties: true and document that keys/values depend on the target tool's schema.
• Add parameter descriptions: 'specContents' → 'OpenAPI 3.x spec as YAML or JSON string. If provided, overrides bundled spec.'; 'arguments' → 'Tool-specific arguments as JSON object. Keys and types depend on the invoked tool's input schema.'
• Document invoke_generated_tool output: {success: boolean, result: object, duration_ms: number, error?: string}. Include error classification (retryable vs fatal).
• Add idempotentHint: false to invoke_generated_tool and document that repeated calls with identical arguments may produce duplicate side effects; recommend idempotency keys or state checks.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry