Agent-native brand naming, domain research, and design systems through one CLI and MCP server.
Identity Forge MCP has 13 tools with schemas and descriptions visible in source code. However, numerous critical gaps prevent a higher score. Tool naming follows verb-first conventions (check_, list_, get_, create_, generate_, apply_, export_, share_, assess_), which is good. Descriptions exist but are quite brief (averaging ~60 chars), below the 194-char baseline for production tools. Parameter descriptions are present but minimal. Critically, NO tools have documented output schemas, responses are completely undocumented, forcing LLMs to guess what fields will be returned and breaking tool chaining. Error handling guidance is absent. Schemas are basic JSON Schema with types but lack constraints (enums, ranges, patterns). STDIO transport caps protocol readiness at 50 regardless of definition quality.
Apply a design theme to a project directory
Assess domain acquisition opportunities
Check domain name availability and DNS status
Create a new brand design project
Create a new brand naming project
Export a brand project
Generate naming candidates for a project
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract returned data without knowing field names and types. This breaks tool chaining and forces agents to guess at response structure.
Tool descriptions are uniformly brief (50-70 chars), below the 194-char production baseline. They lack WHEN to use context and dependencies. E.g., 'Get the current authenticated user account information' omits why an LLM would call whoami, what it returns, or what comes next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
Get the DESIGN.md brief for a theme
Get design tokens in a specified format
List naming candidates for a project
List available design themes and kits
Share a brand project with others
Get the current authenticated user account information
No parameter constraints (enums, min/max, patterns) declared in schemas. E.g., 'format' in get_tokens accepts 'dtcg|css|tailwind-v3|tailwind-v4|shadcn-registry|json' per description but no enum in schema. LLMs will hallucinate invalid format values.
WRITE tools (apply_theme, create_naming_project, generate_names, create_brand_project, share_brand_project) have no error handling guidance or recovery hints. LLMs cannot determine if failures are retryable, user-fixable, or fatal.
List tools (list_themes, list_name_candidates) lack pagination parameters (limit, offset, cursor) and no result limit is declared. Responses may be unbounded, risking context window exhaustion.
Tool composition unclear. E.g., create_naming_project → generate_names → list_name_candidates workflow is documented, but returned IDs and field names linking these tools are not visible in schemas. Agents must infer chaining.
No idempotency guarantees stated for WRITE operations. If create_naming_project or share_brand_project are retried on network failure, will duplicates be created? Agents need this clarity to handle resilience safely.
Parameter 'dir' in apply_theme accepts a file path but no sanitization or format hints are provided. Path traversal or command injection via malicious directory names is possible if input is passed unsanitized to file operations.