This MCP server has severe definition quality issues. Tool schemas are completely absent from the visible source code, only tool names appear in configuration files (setup-mcpServer-json.sh) and partial server.py. No input parameter definitions, no output schemas, and minimal descriptions are visible. The five tools (read_md_files, search_content, get_context, project_structure, suggest_implementation) are declared in the mcp-config.json but their actual implementations and schemas are not present in the provided source. The partial server.py shows a ServerConfig class but does not expose the tool registration with FastMCP decorators and schemas. Without visible schema definitions, per the HARD SCORING RULE, schema scores must be 0. Descriptions in the config file are either missing entirely or trivial (e.g., 'alwaysAllow' list provides no actionable guidance). Tool naming follows basic verb_noun convention, but lacks the specificity required for LLM disambiguation, 'read_md_files' and 'get_context' are vague about scope, data source, and return structure.
CRITICAL: No input schemas visible for any of the 5 tools. Tool definitions exist only in mcp-config.json as names in an 'alwaysAllow' list; actual FastMCP tool registrations with @server.tool() decorators and input_schema parameters are not present in the provided source code chunk.
CRITICAL: No tool descriptions provided. The mcp-config.json lists tools in 'alwaysAllow' but provides no descriptions explaining what each tool does, when to use it, or what it returns. LLMs cannot select tools without descriptions.
HIGH: Ambiguous tool naming. 'get_context' does not clarify whether it returns document context, project context, or code context. 'read_md_files' offers no hint about scope, filtering, or return format. Per naming baseline, names should unambiguously convey the action and resource.
Recommendations
Add explicit FastMCP tool registrations with @server.tool() decorators in src/server.py. Each tool must declare input_schema (JSON Schema object), output schema (via docstring or metadata), and a comprehensive description (50 - 200 characters, explaining WHAT, WHEN, and RETURN VALUE).
For read_md_files: change name to clarify scope, read_project_md_files or read_document_markdown. Add schema with parameters like: file_path (string, required), recursive (boolean, default true), include_frontmatter (boolean, default false). Document output as: { files: [{ path, content, modified_at }], total_bytes, file_count }.
For get_context: clarify what 'context' means, document context? project context? code context? Rename to get_document_context or get_project_metadata. Add schema and output structure.
For project_structure: document what structure is returned (directory tree, file hierarchy, dependency graph). Add schema with optional parameters: root_path (string), max_depth (integer, 1-10, default 5), include_hidden (boolean, default false). Specify output as { structure: object or tree representation, total_files, total_dirs }.
For suggest_implementation: clarify what implementation suggestions are returned (code snippets, patterns, architecture). Add schema with parameters: context (string, description of what to implement), language (enum: python, javascript, go, rust, etc.), style (enum: minimal, detailed, example, production). Return: { suggestions: [{ title, code, explanation, references }], confidence_score }.
HIGH: Tool registration is incomplete. The source code chunk shows ServerConfig initialization and imports of FastMCP, but does NOT show actual tool registration via @server.tool() decorators. If tools are inferred from config only, per HARD SCORING RULE, tool scores are capped at 50.
MEDIUM: No parameter descriptions visible. Tool names like 'search_content' offer no details on what search parameters are accepted, what constraints apply, or what the expected format is.
MEDIUM: No error handling guidance visible. Responses include no recovery hints, error classification (retryable vs. fatal), or actionable next steps for the LLM.
Add per-tool descriptions that explain: (1) what the tool does in one sentence, (2) when an LLM should call it instead of similar tools, (3) any prerequisites or dependencies. Example: 'search_content finds matches within document files by keyword or regex. Call this after read_md_files if you need to locate specific sections. Returns file paths and line numbers for quick navigation.'
Add parameter descriptions for all inputs. For each parameter, state: type, allowed values (enum or range), format/pattern, default, and examples of valid values. Never include example IDs or usernames in descriptions, use enums or pattern declarations instead.
Document return types and schemas in each tool's docstring or via explicit output_schema. Include field names, types, and what each field means. Example: 'Returns { results: [{ path: string, content: string, matches: int }], total: int, has_more: bool }'.
Add error handling to each tool implementation. When a tool fails, return a structured error response with: error_code (string), message (actionable guidance), retryable (boolean), next_steps (what the LLM should try next). Example: 'File not found. Try search_content() with broader filter, or list available files with project_structure().'
Consider adding pagination support to tools that return lists (e.g., search_content, read_md_files). Accept limit and offset/cursor parameters, return total_count or next_cursor, and cap default limit to 20-50 results to avoid context window overload.
Document any file path constraints (e.g., 'relative paths only', 'no .. traversal'). Add input validation with clear error messages for invalid paths.