A comprehensive MCP server providing workspace management, file operations, skill execution, and tool gateway capabilities for agent-driven development workflows
Cloud Harness MCP demonstrates solid definition quality with 15 well-structured tools. All tools have descriptions (avg 95 chars) and explicit input schemas with typed parameters. Tool naming follows verb_noun convention (search, inspect, execute, permissions, status, files_*, grep_search, symbols_*). Schemas include constraints (minLength, maxLength, minimum, maximum, defaults). However, several parameter descriptions are minimal (e.g., 'Workspace-relative path' lacks format guidance), and output schemas are not documented in the provided source. Error handling guidance is absent, tools do not indicate what to do on failure or how to recover. The meta-tools (search, inspect, execute, permissions, status) are well-designed for tool discovery and composition, but file operation tools lack idempotency hints and confirmation patterns for destructive operations.
Run one downstream MCP tool with arguments that match the schema `inspect` returned. The call is re-authorized and routed server-side and is never retried.
Execute the bounded files_apply_patch operation in the validated workspace.
Execute the bounded files_delete operation in the validated workspace.
Execute the bounded files_list operation in the validated workspace.
Execute the bounded files_mkdir operation in the validated workspace.
Execute the bounded files_move operation in the validated workspace.
Output schemas not documented. Tools return results but LLMs cannot plan downstream calls without knowing response structure. Files_* tools should document returned fields (path, size, modified, content, etc.); search/inspect/execute should document their response objects.
Destructive operations (files_delete, files_apply_patch, files_write) lack confirmation or dry-run patterns. No guidance on recovery if agent makes mistakes. Missing idempotentHint annotations.
Parameter descriptions for file operations are minimal. 'Workspace-relative path' does not explain path format, allowed characters, or traversal restrictions. 'expectedSha256' lacks explanation of when/why to use it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2025-06-18+ | v2 |
Execute the bounded files_read operation in the validated workspace.
Execute the bounded files_write operation in the validated workspace.
Execute the bounded grep_search operation in the validated workspace.
Return one MCP tool's real input schema, annotations, availability, and permission. Call it before `execute` so arguments match the upstream schema.
Show the effective allow/deny decision for a tool, for every tool on a server, or for every configured server. Permissions are enforced server-side.
Find an MCP tool by describing what you need. Returns qualified tool names; call `inspect` for the schema and `execute` to run it.
Report each configured MCP server's enabled state, connection state, cached tool count, last connection, and a sanitized error when one is stored.
Execute the bounded symbols_references operation in the validated workspace.
Execute the bounded symbols_search operation in the validated workspace.
No error handling guidance. Tools do not indicate what errors are retryable, user-fixable, or fatal. Missing recovery hints (e.g., 'If file not found, call files_list() to discover available paths').
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared in features but not visible in tool definitions. Verify they are present in the actual MCP server registration code.