No input schemas visible for any tool. All 10 tools lack JSON Schema definitions, parameter types, constraints, and validation rules. This violates the fundamental requirement that every parameter must be typed and described.
Tool descriptions are critically short (5-24 characters) and provide no actionable guidance. Examples: 'Generate formal specification', 'Create API specification'. Descriptions fail to explain WHAT the tool does, WHEN to use it vs similar tools, or WHAT it returns. Minimum viable description is 50-100 characters with clear intent and usage.
Define input schemas in JSON Schema format for every tool. Include type, description, enum/pattern constraints for each parameter. Example: { 'name': 'spec_format', 'type': 'string', 'enum': ['yaml', 'json', 'protobuf'], 'description': 'Output format for specification (yaml, json, or protobuf)' }
Expand tool descriptions to 80-150 characters. Include: (1) what the tool does, (2) when to call it vs similar tools, (3) key outputs. Example: 'Generate a formal specification document in YAML or JSON format from a requirements document. Use this to create executable contracts and state machines. Returns spec_id and spec_url.'
Add 'parameters' field with descriptions for every input. Example: { 'requirements_file': 'Path to requirements document (markdown, docx, or pdf)', 'output_format': 'Format for generated spec: yaml, json, or protobuf' }
Document output schemas. Define what fields are returned, their types, and which are required for downstream tool calls. Example for generateFormalSpec: { 'spec_id': 'UUID of created specification', 'spec_url': 'HTTP URL to access spec', 'format': 'yaml|json|protobuf', 'created_at': 'ISO 8601 timestamp', 'lines_of_code': 'integer, LOC in spec' }
Add error handling guidance to tools. For validateSpec and modelCheck, document possible error conditions and recovery steps. Example: 'Returns error_code and error_message. If error_code is 'syntax_error', LLM should ask user to correct input. If 'missing_dependency', suggest running generateStateMachine first.'
Tool definitions exist only as TypeScript type stubs in artifacts/types/src/mcp-server/formal-server.d.ts. No actual implementation visible. No tool registration code, no handler functions, no parameter validation. This indicates the MCP server is incomplete, tools are declared but not implemented.
No output schemas documented for any tool. LLMs cannot infer what fields to expect, which breaks downstream tool chaining and multi-step planning. Tools returning lists should also document pagination support, limits, and result structure.
No error handling guidance. No recovery hints, error classification, or actionable error messages defined. Tools like 'validateSpec' and 'modelCheck' provide no indication of what errors are possible or how to recover.
Tools marked as WRITE operations (generateFormalSpec, createAPISpec, generateStateMachine, createContracts, generateDiagrams, updateConfig) have no confirmation or dry-run support documented. Destructive/generative operations should support preview-before-execute patterns.
No parameter descriptions provided. For any tool with parameters (not visible in this artifact), LLMs cannot determine what values are valid, what units apply, or what dependencies exist between parameters.
Add confirmation/dry-run support for WRITE tools (generateFormalSpec, createAPISpec, etc). Add optional 'dry_run': true parameter that returns what would be created without committing. Users and agents can preview before committing.
Provide implementation code, not just type stubs. Move from artifacts/types/src/mcp-server/formal-server.d.ts to actual handler registration and execution code. Include validation, error handling, and idempotency checks.
For list tools (listSpecifications), add pagination: 'limit' (default 20, range 1-100) and 'offset' (default 0) parameters. Return 'total_count' and 'next_offset' in response.
Add parameter relationships documentation. If 'output_format' defaults to 'yaml', state this. If certain parameters are mutually exclusive, document it. Example: 'Either provide requirements_file OR requirements_text, not both.'
For tools that resolve names/identifiers (getSpecification), document whether spec_id (UUID) or spec_name (human-readable) are accepted. Support both to match user chat data model.