Generate a Nimbus MCP connector package from a small JSON spec — for the Nimbus monorepo, or standalone.
This is a code generator (create-nimbus-connector), not a production MCP server. The 6 tools in fixtures/snapshots are GENERATED EXAMPLES, not the actual server being evaluated. The generator itself has no tools. Tool definitions in snapshots show basic schemas and descriptions but lack depth: descriptions are 10-30 chars (well below 50-200 char baseline for LLM optimization), parameters lack type constraints (enums, ranges), no output schemas documented, no error handling guidance. The generator code (src/derive/server/tools-hand.ts) shows sophisticated AST parsing but does not itself expose tools to clients. Scoring reflects the generated example quality, which is minimal.
Create an item.
Delete an item by id.
List items.
Create an item.
List items.
Update an item's title.
Descriptions are 10-30 characters, far below the 50-200 char baseline for LLM optimization. 'List items.' and 'Create an item.' lack context for when/why to call the tool.
No output schemas documented. LLMs cannot infer what fields are returned or plan downstream tool calls. E.g., zzwrite_item_list returns what? Array of items with which fields?
Parameters lack enums, ranges, or format constraints. 'scope' and 'mode' are free-form strings with no guidance on valid values. 'draft' is boolean but no description of what true/false means.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
No error handling guidance. If delete fails (item not found, permission denied), LLM has no recovery path. No distinction between retryable and fatal errors.
Destructive tool (zzwrite_item_delete) has no confirmation step or dry-run option. Agents can delete items without safeguards.