Gatana exposes 15 tools for MCP server management. While the server provides explicit tool registration with schemas and descriptions, the quality is significantly below production standards. Critical gaps: (1) Most tool descriptions are under 50 characters and lack context about WHEN to use the tool or WHAT happens to system state. Examples: 'List all MCP servers' (23 chars), 'Delete an MCP server by slug' (28 chars). (2) Parameters lack depth, descriptions are minimal and fail to explain expected formats, ranges, or allowed values. For example, 'transportConfig' in createServerV2 accepts an object with 'type' enum and 'runtime' string, but the runtime parameter has zero explanation of valid values (is it 'node24', 'python3.11'?). (3) Output schemas are not documented anywhere in the visible code, LLMs cannot see what createServerV2 or callMcpServerTool return, forcing blind reasoning. (4) Error handling is absent from tool definitions, no guidance on retryability, user-fixable errors, or recovery steps. (5) Tools like callMcpServerTool and uploadZipToFunction combine multiple concerns (tool lookup + execution, file transport + deployment) without clear separation. (6) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels documented (DESTRUCTIVE, WRITE, READ_ONLY). (7) Parameter naming is inconsistent: 'serverSlug' vs 'slug', 'toolName' vs 'name', 'onlyEnabled' vs boolean flags elsewhere. Baselines: average tool description is 194 chars (Gatana avg ~40); 100% of A+ tools have param descriptions (Gatana ~30%); 90% of A+ tools start with action verbs (Gatana 100% ✓ but descriptions don't support selection).
Tools (15)
callMcpServerToolwriteauth48/100
Call a tool on an MCP server
createServerV2writeauth45/100
Create a new MCP server
deleteMcpServerdestructiveauth50/100
Delete an MCP server by slug
getDeploymentsStatusread onlyauth50/100
Get deployment status for a server
getMcpServerToolread onlyauth50/100
Get detailed information about a specific tool on an MCP server
getServerV2read onlyauth47/100
Get detailed information about a specific MCP server
Output schemas missing for all 15 tools, LLMs cannot reason about returned data structure, field names, or types. Blocking pattern:tool and pattern:response-shaper compliance.
Add output schemas to ALL tools. For each, document: returned field names, types, and usage context. Example: 'createServerV2 returns { serverId: string, slug: string, status: 'initializing'|'running'|'stopped', createdAt: ISO8601 }.' This enables LLM to plan downstream calls and extract IDs needed for chaining.
Expand tool descriptions to 100 - 200 characters. Follow: WHAT does it do? WHEN should LLM call it vs similar tool? WHAT are prerequisites? WHAT state changes? Example: 'Delete an MCP server and all its deployed tools. Use after migrating to a new server. WARNING: irreversible. Servers in use by agents cannot be deleted.'
Add error recovery guidance to all WRITE/DESTRUCTIVE tools. Example in deleteMcpServer: 'If server is in use, error "ServerInUseError" is returned. First call listServersV2 to check status, then move any dependent agents to a new server before retrying.'
Standardize parameter names: always use 'serverSlug' (not 'slug' or 'serverId'), 'toolName' (not 'name'), 'podName' only if podName is user-obtainable (else provide a tool to list pods). Document parameter format: 'serverSlug must match regex ^[a-z0-9-]{1,32}$'.
Remove 'V2' from tool names. If V1 and V2 coexist, clarify in the description (e.g., 'Use this version if your server was created after 2024-01-01'). Otherwise, rename to canonical names: 'listServersV2' → 'listServers', 'getServerV2' → 'getServer'.
Replace examples in parameter descriptions with enum constraints. In listAuditLogs, change 'entityTypes: array of strings, e.g. mcp_server, mcp' to 'entityTypes: array of enum values from ["mcp_server", "mcp_tool", "mcp_resource"]'. Let LLM auto-complete from valid set.
Score history
Overall score trend
↑ 2 points across a rubric change (v1 → v2)
48/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
48
2025-06-18+
v2
2026-03-09
F
46
-
v1
listDeploymentsLogsread onlyauth50/100
List deployment logs for a server
listMcpServerToolsread onlyauth50/100
List all tools on a specific MCP server
listServersV2read onlyauth33/100
List all MCP servers
listToolsread onlyauth50/100
List all available tools across MCP servers
refreshToolswriteauth50/100
Refresh the list of tools available on an MCP server
startServerwriteauth50/100
Start a hosted MCP server
uploadZipToFunctionwriteauth50/100
Upload a deployment package ZIP file to a hosted MCP server
'V2' suffixes in tool names (listServersV2, getServerV2, createServerV2, listCredentialsV2) expose implementation versioning to LLMs, violating pattern:tool-name clarity. Creates confusion when both V1 and V2 exist or when V1 is removed.
Inconsistent parameter naming across tools: 'serverSlug' vs 'slug' vs 'serverId'; 'toolName' vs 'name'; 'podName' appears nowhere else. Increases LLM reasoning overhead and invites parameter mismatches.
Tool descriptions too short and generic (avg ~40 chars vs baseline 194 chars). Most omit WHEN to use the tool, prerequisites, and consequences. 'List all MCP servers' (22 chars) gives LLM no context for selection.
Parameter descriptions missing or minimal. 'runtime' in createServerV2 has no description of valid values (node24? python3.11?). 'limit' in listAuditLogs is typed as string, should be number. 'previous' in listDeploymentsLogs is string but semantics unclear.
Examples embedded in parameter descriptions (listAuditLogs: 'e.g. mcp_server, mcp') violate pattern:tool-description rule. Should use enum constraints instead, allowing LLM to select from valid set without hallucinating.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit Risk levels documented in server spec. Risk levels should be expressed as tool annotations per pattern:tool.
Credentials exposure risk (listCredentialsV2) undocumented. Tool description doesn't warn whether secrets are returned plaintext, hashed, or redacted. No guidance on scope restrictions or usage sensitivity per pattern:secret-injection.
Combined concerns in single tools: callMcpServerTool merges tool discovery + execution; uploadZipToFunction merges file transport + deployment state change. Pattern:tool requires single responsibility.
callMcpServerTooluploadZipToFunction
Fix parameter type inconsistencies: 'limit' in listAuditLogs should be number with bounds (1 - 1000), not string. 'previous' in listDeploymentsLogs should be boolean, not string, with description 'if true, fetch logs from the previous failed deployment'.
Add tool annotations to tool registration: mark deleteMcpServer/createServerV2/uploadZipToFunction/startServer/refreshTools with { "destructive": true } or { "idempotent": false } to signal to LLM. Mark read-only tools with { "readOnly": true }.
Document credentials handling explicitly. In listCredentialsV2 description: 'Returns API keys and OAuth tokens. Tokens are truncated to first 8 chars for security. To use a credential, pass its ID to other tools (do not extract and reuse the token).'
Split combined-concern tools: callMcpServerTool should not discover tools; assume tool name is known. If discovery is needed, separate into 'listMcpServerTools' (which exists but is weak). Rename 'uploadZipToFunction' to 'deployServerPackage' and document: 'Uploads ZIP, validates, and triggers deployment. Use startServer separately to control when the server activates.'
Add pagination to list tools. listTools, listServersV2, listMcpServerTools, listAuditLogs should accept 'limit' (1 - 100, default 20) and 'offset' or 'cursor' parameters. Return { items: [...], total: number, nextCursor?: string } to handle large result sets without blowing context window.
Document dry-run pattern for destructive ops. Example in deleteMcpServer: Add optional 'dryRun: boolean' parameter. When true, returns what WOULD be deleted without executing. Agents can validate before committing.
Add 'createdAt', 'updatedAt', 'userId', 'requestId' fields to all responses for traceability. Per pattern:audit-trail, tool responses should enable blame/debugging. Example: 'deleteMcpServer returns { deleted: true, serverId: string, deletedAt: ISO8601, deletedBy: string, requestId: string }'.