emmett-mcp exposes three decorator functions (tool, prompt, resource) as 'tools', but these are NOT actual agent tools in the MCP sense. The source code shows these are Python decorators used to register handlers with the MCP module, not executable tools that an LLM agent would call. The 'tool' decorator accepts optional name and description parameters but provides no mechanism to define input schemas, output schemas, or error handling for decorated functions. The prompt and resource decorators similarly lack proper tool definition structure. Critically, there is no visible schema generation, parameter validation, or documentation of what each decorated function actually does when invoked. The input parameters shown (name, description for tool/prompt; uri, name, description, mime_type for resource) describe the DECORATORS themselves, not the tools they register. This is a fundamental architectural mismatch: the MCP specification requires tools to have explicit input schemas, descriptions, and output structures, emmett-mcp provides a decorator API that does not enforce or expose these. Without access to the actual tool handler implementations (which would be user-defined functions decorated with @tool, @prompt, @resource), it is impossible to evaluate the schema quality of any actual registered tools. The three items listed are meta-tools for registration, not domain tools.

• Clarify that 'tool', 'prompt', and 'resource' are registration decorators, not domain tools. Document the actual tools that users define via @tool/@prompt/@resource, and provide examples with full input/output schemas.
• Define explicit JSON Schema for the input parameters of each decorator. For 'tool': {"type": "object", "properties": {"name": {"type": ["string", "null"], "minLength": 1, "maxLength": 100, "pattern": "^[a-zA-Z_][a-zA-Z0-9_]*$", "description": "Alphanumeric identifier, 1-100 chars, must start with letter or underscore. Defaults to function name if omitted."}, "description": {"type": ["string", "null"], "minLength": 10, "maxLength": 1024, "description": "Tool description for LLM selection, 10-1024 chars. If omitted, docstring from decorated function is used."}}}
• Expand tool and parameter descriptions to 50-200 characters. Example: 'Registers a Python function as an MCP tool. The decorated function will be invoked by the LLM agent with parameters matching the function signature. Optional name overrides the function name; optional description overrides the docstring. Returns a registration confirmation with tool_id and URI.'
• Document the output structure when a tool is successfully registered. Return at least: {"status": "registered", "tool_name": "string", "tool_id": "string", "input_schema": {...}, "uri": "string"}
• Add validation rules: tool names must be unique within the module; names must match ^[a-zA-Z_][a-zA-Z0-9_]*$; descriptions must be non-empty if provided; resource URIs must be valid URI templates.