Model Context Protocol server implementation with TypeScript for reading Google Cloud Logging entries via gcloud CLI
Two tools with visible schemas and descriptions, but significant quality gaps. 'read' tool has a complex schema with 12 parameters, most optional, but descriptions are generic and lack actionable guidance (e.g., 'Filter expression for log entries' doesn't explain syntax or examples). 'docs' tool is minimal with only one enum parameter. Neither tool description explains when to use it, what it returns, or prerequisites. No output schemas documented. Error handling returns raw error messages without recovery guidance. Parameter descriptions lack format constraints, ranges, or examples. No tool annotations (readOnlyHint, idempotentHint). Naming is acceptable ('read', 'docs') but descriptions fall short of the 50-200 char LLM-optimized baseline (read: 95 chars, docs: 62 chars). Overall, definitions are present but underdeveloped for agent reasoning.
Retrieve documentation from doc.yaml file, optionally filtered by type
Read Google Cloud Logging entries using gcloud CLI with configurable filters and options
Tool descriptions lack actionable context. 'read' says 'Read Google Cloud Logging entries using gcloud CLI with configurable filters and options' but does not explain when to use it, what filters are valid, or what the output contains. LLMs cannot determine tool selection without this context.
No output schema documented. The 'read' tool returns filtered log entries but the response structure is not specified. LLMs cannot plan downstream operations or extract required fields without knowing the output shape.
Parameter descriptions lack format constraints and examples. 'logFilter' is described as 'Filter expression for log entries' but does not explain the syntax (e.g., 'resource.type=gce_instance AND severity=ERROR'). 'limit' has no range (e.g., 1-1000). LLMs will guess invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
Error handling returns raw error messages without recovery guidance. Code catches errors and returns 'Error: {message}' but does not tell the LLM what to do next (retry, check parameters, call a different tool). Agents cannot self-correct.
No tool annotations. Neither tool declares readOnlyHint, destructiveHint, or idempotentHint. The 'read' tool is read-only and idempotent but this is not signaled to the agent, forcing it to reason about safety.