Validate a StackForms (.forms.yml) file using the Cycloid CLI. This tool can validate StackForms configuration and provide detailed feedback for fixing issues.
| Name | Required | Description | Default |
|---|---|---|---|
| forms_content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It mentions the tool uses the Cycloid CLI and provides detailed feedback, but does not disclose whether it is read-only, required auth, or what the feedback format looks like. Some context is added, but it is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the second sentence partially restates the first ('validate' is repeated). It is concise but slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter details, the description leaves important questions unanswered: what is the expected input format, what does the feedback look like, and how are errors surfaced? It is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'forms_content' parameter—whether it is a file path, inline YAML content, or the expected format. The description mentions validating a file but does not map the parameter to that file content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool validates a StackForms (.forms.yml) file using the Cycloid CLI, with a specific verb and resource. This clearly distinguishes it from sibling tools that list blueprints, create stacks, or list events/pipelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to validate StackForms configuration and get feedback for fixing issues. No sibling tool offers validation, so context is clear, though it does not explicitly say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct Cycloid resource or action: blueprints, catalog repos, events, pipelines, stack creation, and StackForms validation. No two tools overlap in purpose, and the detailed descriptions further clarify their specific roles.
All tool names follow the CYCLOID_ prefix with an action verb at the end (LIST, CREATE, VALIDATE). However, the middle parts vary between simple nouns (EVENT, PIPELINE) and compound nouns (BLUEPRINT_STACK, CATALOG_REPO), creating slight inconsistency in granularity.
With 6 tools, the server is well-scoped and easy to navigate. Each tool has a clear purpose, and the count falls within the ideal 3-15 range for a domain-specific MCP server.
The surface is heavily read-oriented with four of six tools being list operations. There are notable gaps, such as no get/detail for specific resources, no update/delete operations, and no creation for most resource types. Only stack creation and StackForms validation provide write/validation functionality, leaving workflows incomplete.
