MCP server for Common Ninja widget management, project operations, CRM contacts/submissions, and analytics
Server has 15 tools with consistent naming (verb_noun pattern) and present descriptions. However, descriptions are often generic and lack actionable context for LLM selection. Parameter schemas use Zod with basic types but lack enums, ranges, and detailed constraints. No output schemas documented. Error handling is minimal, most tools return generic success messages without recovery guidance. Missing tool annotations (readOnlyHint, destructiveHint). Composition is reasonable but some tools (e.g., update_widget) have complex multi-step workflows that could be better documented.
Create a new widget with the specified type and data. Optional props with an object type under `styles` should be empty or populated objects.
Get project details by ID
Get widget data by ID before updating widget data for a reference.
Get the editor URL for a widget
Get the embed code for a widget
Get widget schema by type before updating widget data. Always follow the schema when updating widget data, don't add any new fields because validation will fail.
No output schemas documented. Tools return text/JSON responses without declaring expected fields, forcing LLMs to parse unstructured output and guess at downstream field names.
Parameter descriptions lack constraints. Numeric params (page, limit) have no min/max bounds; string params (widgetType, projectId) have no enum or format guidance. LLMs may pass invalid values.
Tool descriptions are generic and lack actionable context. E.g., 'Get widget data by ID before updating widget data for a reference' does not explain WHEN to call this vs other tools or what the LLM should do with the result.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Get a list of all available widget types
List all projects with pagination
List all widgets in the account with pagination
Get project's contact details by ID
Get project's submission details by ID
List all project's contacts with pagination
List all project's submissions with pagination
Merge current widget data with new partial widget data. `nextWidgetData` should be only the fields or sub-objects that are being updated. For arrays, always return the new array.
Validate JSON schema before updating or creating a widget with the updated widget data and schema
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot determine which tools are safe to retry or have side effects without explicit hints.
Error handling is minimal. Tools return generic 'Widget updated successfully' without recovery guidance. If validation fails or API calls error, LLMs have no actionable next steps.