The Mynd MCP server defines 6 tools with partial schema information visible in the source code excerpt. All tools have descriptions and named parameters, but the schema definitions are incomplete, parameter type information is inferred from the input dicts rather than explicitly declared in JSON Schema format. The codebase shows Pydantic models (ContextRequest, TokenRequest) that define schemas, but these are not directly mapped to the tool registration in the MCP protocol layer. The descriptions are generally adequate (100-200 chars) but lack actionable guidance on when to use each tool vs. alternatives, and error recovery steps are missing. Parameter descriptions exist but many lack format constraints, enums, or range guidance.

• Make tool registration explicit in the MCP protocol layer. Ensure each tool is registered with name, description, inputSchema (as JSON Schema with 'type', 'properties', 'required' fields), and documented outputSchema. Pydantic models should be converted to JSON Schema and exposed in the MCP response.
• Add enum constraints for parameters with known values. For create_capability_token, define scope as enum: ['context_read', 'context_search', 'token_manage']. For get_context, enumerate source_types options.
• Document output schemas explicitly. For each tool, declare what fields are returned. Example for get_status: {'type': 'object', 'properties': {'server': {'type': 'string'}, 'database': {'type': 'object'}, 'vector_store': {'type': 'object'}, 'active_tokens': {'type': 'integer'}, 'capabilities': {'type': 'array', 'items': {'type': 'string'}}}}.
• Expand tool descriptions to answer WHAT, WHEN, and WHAT IT RETURNS. Example: 'Get relevant context (documents, code snippets, metadata) from the vector store for a natural language query. Requires a valid capability token (create_capability_token first). Returns up to max_tokens of ranked context and source metadata. Use this when the LLM needs background information to answer a user question.'
• Differentiate get_context and search_context in documentation. Clarify which is authenticated, which requires token scope, and what performance/behavior differences exist. Consider merging if they're redundant or renaming one for clarity (e.g., search_context → search_context_simple).