A MCP server project for managing cloud workspaces and instance types across multiple providers
brev-mcp has two tools with clearly registered schemas and descriptions, but both suffer from incomplete parameter documentation and vague descriptions that don't guide LLM selection. The naming is verb-forward (get_, create_), which is correct. However, parameter descriptions are minimal or missing, schema completeness is partial, and error handling is non-existent. The 'create_workspace' tool lacks critical parameter validation and recovery guidance. Descriptions are present but fall short of the 50-200 character LLM-optimized baseline, they don't explain WHEN to use each tool vs alternatives or what the prerequisites are.
Create a workspace from an instance type and cloud provider
Get available instances types for a cloud provider
Incomplete input validation and error messaging. Both tools check for required parameters at runtime with generic ValueError, but provide no guidance on valid values, constraints, or recovery paths. 'cloud_provider argument is required for get_instance_types tool' tells the LLM the parameter is missing, but not what values are valid or how to proceed if the provider is unknown.
create_workspace description is vague: 'Create a workspace from an instance type and cloud provider' (57 chars) does not explain WHEN to use this tool, what happens after creation, whether it's async, or what the expected output structure is. The description should state: 'Creates a new workspace on the specified cloud provider with the given instance type. This is a destructive operation, the workspace will incur charges. Returns workspace ID and connection details.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Missing parameter descriptions for 'name' and 'instance_type' in create_workspace. 'name' has description 'The name of the workspace' (27 chars, below 50-char baseline), and 'instance_type' has description 'The instance type of the workspace' (34 chars). These don't explain format constraints (e.g. alphanumeric, length limits, special characters allowed), or that the value should match one of the instance types returned by get_instance_types. LLM has no guidance on valid values.
create_workspace requires 'instance_type' but does NOT require 'name' in the schema (only cloud_provider and instance_type are required per the schema's 'required' field showing just ['cloud_provider']). However, the tool implementation checks for all three: 'if "name" not in args or ...'. This mismatch means the LLM may not know 'name' is required, it could omit it and get a runtime error.
No output schema documented. get_instance_types returns TextContent with raw text (likely JSON string). create_workspace returns TextContent with unspecified content. LLMs need to know: Is the output a JSON object, array, or plain string? What fields does it contain? How should the LLM extract workspace_id or other IDs for downstream operations? Without this, the LLM cannot reliably chain tools.
get_instance_types description is minimal: 'Get available instances types for a cloud provider' (52 chars). Does not explain: What structure is returned? Is it a list of instance names, a table with pricing/specs, or a nested object? When should the agent call this vs reading a resource? This ambiguity forces the LLM to guess or make extra exploratory calls.
No error classification or recovery guidance. If create_workspace fails due to quota, invalid cloud_provider, or network timeout, the tool returns a bare RuntimeError. The LLM doesn't know: Should I retry? Ask the user to check their org limits? Use a different provider? A recovery-guide pattern response would say: 'Quota exceeded for cloud provider aws. Try another provider (gcp, azure) or contact support to increase your quota.'
No documented resource relationships. The 'instance_type' parameter in create_workspace should match values returned by get_instance_types, but this dependency is not documented in either tool's description. LLMs should be told: 'First call get_instance_types to discover valid instance_type values for the chosen cloud_provider, then pass one to create_workspace.'