This is a test/demonstration MCP server ('mcp-surfaceprint') designed to analyze OTHER MCP servers, not to be a production tool server itself. Evaluation reveals fundamental quality issues: (1) Duplicate tool names across files (list_items, get_item, create_item, delete_item, ping appear 2-3 times; always appears twice) indicate test fixtures rather than a coherent API surface. (2) Most tools have minimal or absent parameter descriptions, 'list_items' and 'task' have no visible inputSchema documentation. (3) Tool descriptions are extremely brief (6-25 chars) and lack context for LLM selection. (4) No output schemas documented anywhere. (5) No error handling patterns or recovery guidance visible.
Most tools lack input schemas or parameter documentation. list_items, always, noop, home_* flags, and ping have no visible inputSchema in code. Tool descriptions do not document what parameters are required or their meaning.
Tool descriptions are extremely brief (<25 chars) and lack actionable context. 'Say hello' (greet), 'Get the current time' (get_time), 'No-op tool' (noop), 'Always present' (always, ping) do not explain WHEN to use the tool or what it DOES in meaningful detail.
greet
Recommendations
Consolidate duplicate tool names. If these are intentional variants (e.g., for different auth gates or CWD contexts), rename them distinctly: list_items_open, list_items_auth, list_items_public, etc. Duplicate names will cause LLM confusion and routing errors.
Add full input schemas with type and description for every parameter. E.g., for get_item: inputSchema must include item_id with type 'string' and description 'The unique identifier of the item to retrieve (format: UUID or numeric ID).'
Expand all tool descriptions to 50-150 chars, answering: What does this do? When should the LLM call it? What does it return? Example: 'Get the current time in UTC ISO 8601 format. Call this when the agent needs to know the current time for scheduling or time-based decisions.'
Document output schemas for every tool. Define the response structure (e.g., {type: 'object', properties: {id: {type: 'string'}, name: {type: 'string'}, ...}}). This enables LLMs to extract and chain data.
Rename 'always' to a verb-based name reflecting its actual purpose. If it checks feature flags or server state, call it check_feature_flags or describe_server_state. If it is a no-op for testing, rename to test_noop_tool.
Rename 'frobnicate' to a clear action verb. From context ('An oddly-named tool with no obvious verb'), this appears to be a test tool. Rename to process_data, transform_item, or whatever it actually does.
Add error recovery guidance to tool descriptions. E.g., for list_items: 'Returns empty list if database is empty. If the call times out, retry after 5 seconds.'
Tool 'always' and 'frobnicate' have poor naming. 'always' is not a verb and conveys no action. 'frobnicate' is jargon and obscures intent. Tool names should start with action verbs (get_, create_, list_, etc.) for LLM clarity.
No output schemas documented for any tool. LLMs cannot predict what fields or data structure they will receive, making downstream tool chaining and field mapping impossible.
Destructive tools (delete_item) lack confirmation or dry-run patterns. No documentation of irreversibility or recovery steps.
delete_item
For delete_item, add a confirmation pattern: either require a confirm_delete call first, or return a dry-run mode showing what would be deleted before the destructive call executes.
Add parameter descriptions to create_item and task. E.g., for task's 'action' parameter: 'The action to perform: create, update, delete, or status. Other actions will return an error.'
Group related tools by resource (e.g., all item operations: list_items, get_item, create_item, delete_item) and ensure consistent naming, schema structure, and error patterns across the group.