Facets Control Plane MCP Server for discovering, creating, and managing infrastructure resources in Facets projects using organization-specific abstractions
The server presents 13 well-structured tools with generally clear naming and descriptions. However, there are notable gaps in schema completeness, parameter type specificity, and error handling guidance. Tool names follow verb_noun conventions (get_, create_, update_, delete_) which is good. Descriptions are present and reasonably detailed (averaging ~150-250 chars), meeting the 10-1024 char baseline. Most parameters include type declarations and descriptions. The primary weaknesses are: (1) some parameter descriptions lack constraint details (enums, ranges, formats), (2) output schemas are not explicitly documented in the visible source, (3) error handling lacks recovery guidance, and (4) some tools like 'add_or_update_override_property' and 'remove_override_property' could benefit from clearer dependency documentation. The server demonstrates competent tool design but falls short of production-grade rigor in several dimensions.
Safely add or update a specific property in the resource overrides. This function retrieves the current overrides, adds or updates the specified property, and then applies the modified overrides. It will not overwrite other existing overrides.
Create a new variable or secret in the current project. **Purpose & Context:** Variables and secrets store configuration values and sensitive data that can be referenced by resources across the project. Variables are plain text values, while secrets are encrypted values for sensitive data like passwords and API keys.
Delete a variable from the current project.
Get all environments (clusters) available in the current project. **Purpose & Context:** Environments represent deployment targets where your resources run (e.g., dev, staging, production). Each environment typically corresponds to a separate cluster or cloud account. This function discovers what environments are available for deploying and managing resources.
Retrieve and return the names of all projects (also called stacks) in the system. **Purpose & Context:** Projects are the top-level containers that group related infrastructure resources together. Each project can contain multiple environments (dev, staging, prod) and resources (services, databases, etc.). This function provides discovery of available projects before selecting one to work with.
Output schemas not explicitly documented. Tools like get_all_resources_by_project return Dict[str, Any] with prose descriptions ('resources: List of resource objects', 'pagination: Metadata') but no formal JSON schema. LLMs cannot reliably plan downstream tool calls or extract nested fields without structured output specifications.
Parameter 'variable' in create_variable and update_variable is typed as object with description 'VariablesModel object...' but no schema details. LLMs cannot infer required subfields (value, description, secret flag) or their types. Should document: {value: string, description: string, secret: boolean}.
Error handling lacks recovery guidance. Tools return errors (e.g., 'resource not found', 'permission denied') with no actionable next step. Should follow: 'Resource type not found. Try get_all_resources_by_project() to discover available types' or similar.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Get all resources for the current environment (cluster) with pagination and filtering. Returns paginated list of resources with metadata. Default returns first 50 resources. Use limit/offset for pagination, search for name filtering, resource_type for type filtering.
Get all resources for the current project with pagination and filtering. Returns paginated list of resources with metadata. Default returns first 50 resources. Use limit/offset for pagination, search for name filtering, resource_type for type filtering.
Get the current environment details. 🔍 This requires the current project and environment to be set. 🔄 The function refreshes environment information from the server to ensure data is not stale. ✨
Get a specific resource by type and name for the current environment (cluster). This returns the resource configuration including the base JSON, overrides, effective configuration (deep merge of base + overrides), and override flag.
Get a specific resource by type and name for the current project. This returns the current configuration of the resource. The "content" field contains the resource's actual configuration that would be validated against the schema from get_spec_for_resource() when making updates.
Remove a specific property from the resource overrides. This function removes only the specified property from the overrides, leaving all other overrides intact. Empty parent objects are automatically cleaned up.
Update an existing variable in the current project.
Set the current working environment (cluster) for all subsequent environment-specific operations. **Purpose & Context:** This is a **CRITICAL ENVIRONMENT-CONTEXT** function that establishes which deployment target (dev, staging, production) you want to work with. Many advanced operations require both project AND environment context to be set. Think of this as selecting which cluster/environment to "connect to" for operations.
Constraint documentation missing for string parameters. 'property_path' in add_or_update_override_property uses dot-separated notation (e.g. 'spec.replicas') but lacks regex pattern or format constraint. Should specify: 'Dot-separated path matching pattern ^[a-z_]+(\.[a-z_]+)*$'.
Tool composition dependencies undocumented. Agents must call use_environment() before environment-specific tools (get_resource_by_environment, add_or_update_override_property), and get_all_projects() before use_environment(). These are prerequisite chains but lack explicit guidance in descriptions.
update_variable description is minimal ('Update an existing variable in the current project.') with no detail on behavior differences from create_variable. Will LLM retry failed creates with update? What fields can be changed? Idempotency unclear.
Enum constraints missing. resource_type parameters accept strings like 'service', 'postgres', 'redis', 'mongo' but are not declared as enums. Should be enum: ['service', 'postgres', 'redis', 'mongo'] to prevent hallucinated invalid values.
Destructive operation (delete_variable) requires confirmation via 'confirmed_by_user' boolean parameter. However, no dry-run or preview capability. If LLM passes confirmed_by_user=false, the tool silently fails, unhelpful. Should provide explicit error: 'Deletion requires confirmed_by_user=true. Confirm with user first.' with clear recovery path.
Pagination parameters (limit, offset, search, resource_type) documented in prose but lack validation constraints. What is max limit? Min offset? Max search string length? Should specify: limit (1-100, default 50), offset (0+), search (max 256 chars).
Tool names 'add_or_update_override_property' and 'remove_override_property' contain 'or_update' and 'property' which are vague. Better: 'set_resource_override' and 'unset_resource_override' (clearer semantics) or 'update_resource_property' and 'delete_resource_property' (more familiar verbs).