Generate an ExisJS boundary.ts to apply middleware, CORS, and dependency injection to a folder route. Specify the file path and functional or OOP paradigm.
Scaffolds an idiomatic ExisJS Boundary (boundary.ts) for applying middleware/CORS/DI to a folder route.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | No | The path to the boundary file to create (e.g., src/http/admin/boundary.ts). | |
| paradigm | No | The ExisJS routing paradigm to use. |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full disclosure burden. It only says “scaffolds,” but does not disclose whether existing files are overwritten, whether a route must already exist, whether side effects occur, or what is returned. For a file-generating tool, this is thin.
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?
One focused sentence, front-loaded with the action and object, and no redundant repetition of the tool name or schema details.
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?
For a simple generator with fully documented parameters, the description is mostly sufficientUTE. It lacks information about defaults, behavior when the target file exists, and whether any prerequisites are required, leaving some ambiguity for a safe call.
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 100%, so the baseline is 3. The description adds a little context around the purpose of the generated file, but it does not expand on the meaning of filePath or paradigm beyond the schema.
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 states a clear, specific action ('Scaffolds'), the exact artifact ('boundary.ts'), and its purpose ('applying middleware/CORS/DI to a folder route'). This cleanly distinguishes it from the other generate-* sibling tools.
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?
It gives clear context for when to use the tool: creating a boundary.ts for middleware/CORS/DI on a folder route. It does not mention alternatives or exclusions, but the use-case is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.