Create production-ready MCP (Model Context Protocol) servers from databases or OpenAPI specs, with an optional ZTAI zero-trust security shield.
mcpfoundry is a code generator, not a production MCP server. It generates tool definitions dynamically from database schemas and OpenAPI specs. The 6 tool templates (list_<table>, create_<table>, get_<table>, update_<table>, delete_<table>, <operationId>) lack concrete schemas, descriptions are minimal (10-20 chars), and parameter documentation is sparse. Tools are inferred from templates rather than explicitly registered. No error handling guidance, no output schema documentation, and no security annotations visible. The generated code shows SQL injection protection (qid() escaping) and basic HTTP handling, but the tool definitions themselves are incomplete.
OpenAPI operation mapped to MCP tool (method and path extracted from OpenAPI spec).
Insert a new row into a database table.
Delete a database table row by primary key.
Fetch a single database table row by primary key.
List rows from a database table with limit and offset pagination.
Update a database table row by primary key.
Tool definitions are templates, not concrete schemas. No explicit input/output schemas visible for any tool. Parameter types and descriptions are inferred from code generation logic, not declared in tool registration.
Descriptions are too short (10-20 chars). 'Insert a new row into a database table' and 'Update a database table row by primary key' lack context on when to use, what happens, and prerequisites. LLMs cannot reliably select tools with such minimal guidance.
No error handling guidance. Generated code returns JSON responses but does not document what errors look like, how to recover, or what the LLM should do on failure. No actionable error messages.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2026-07-28+ | v2 |
No output schema documentation. Tools return JSON but the structure is not declared. LLMs cannot plan downstream calls or extract fields reliably without knowing response shape.
OpenAPI tool naming is generic ('<operationId>'). No verb prefix, no clarity on what the operation does. LLMs cannot infer intent from the name alone.