DreamFactory MCP has critical definition quality gaps. While 8 tools are explicitly registered in src/tools.ts with basic Zod schemas, most parameter descriptions are missing entirely, tool descriptions lack actionability, and error handling is generic. The server exposes database operations but provides minimal guidance on when to use tools or how to interpret results. Naming is acceptable (get_*, list_*, call_*) but descriptions are uniformly brief and non-specific. Output schema documentation is absent. Several tools accept complex filtering parameters (filter, order, group, related in get-table-data) but these are poorly described, forcing LLMs to guess intent.
Output schema documentation entirely missing. Tools return generic JSON responses with no structured field documentation. LLMs cannot plan downstream calls or extract specific fields without trial-and-error.
Generic, non-actionable error messages. All tools catch errors and return 'Failed to fetch data from the API' or similar, with no guidance on root cause or recovery steps. LLMs cannot diagnose or self-correct.
Expand all tool descriptions to 100-200 characters. For example, 'Get tables available in the database' should become: 'Retrieve a list of all tables in the connected DreamFactory database. Returns table names, row counts, and metadata. Call this first to explore available data sources before querying individual tables.'
Document the return schema for every tool in a structured format. Example for get-table-data: 'Returns: { tables: [ { name: string, field_count: number, row_count: number, fields: [ { name: string, type: string } ] } ], total_count: number, returned_count: number }'
Replace generic error messages with specific, actionable guidance. Example: 'Table "orders" not found. Available tables: order, order_detail, order_items. Did you mean "order"? Call get-tables() to see all available tables.'
Add parameter descriptions with syntax and constraints for filter, order, group, and related in get-table-data. Example: 'filter: DreamFactory filter syntax (e.g., "status=active AND created_date>2024-01-01"). See DreamFactory API docs for full syntax.'
Document call-stored-procedure and call-stored-function behavior: expected parameters (are they positional? named?), return types, side effects, and idempotence. Add a note if these are non-idempotent.
For call-stored-procedure and call-stored-function, add a confirmation_required parameter or describe a two-step confirm pattern: first call with a 'dry_run' flag, then execute after user approval.
Add pagination documentation to get-table-data: 'Results are paginated. Default limit=10, max=1000. offset is 0-indexed. Responses include total_count to indicate if more results are available. Use offset and limit to iterate: offset = previous_offset + previous_limit.'
Tool descriptions are too brief (10-50 characters) and lack context on WHEN to use the tool, WHAT it returns, and ANY prerequisites. Examples: 'Get tables available in the database' (44 chars) does not explain if this lists table names only or includes metadata, schema hints, or row counts.
Complex parameters lack descriptions. get-table-data has 'filter', 'order', 'group', 'related' with only inline Zod descriptions; these should explain format, SQL-like syntax expectations, and relationship to DreamFactory API conventions. LLMs cannot form valid filter strings without examples or syntax rules.
Missing parameter descriptions on output schema. Tools like call-stored-procedure and call-stored-function accept only a bare procedureName/functionName string with minimal guidance on whether parameters are passed separately, what return types to expect, or error conditions specific to stored procedures.
No pagination guidance documented. get-table-data accepts offset and limit (default 10), but no description clarifies maximum result set size, whether offset is 0-indexed, or how to handle large tables.
No tool composition chain documented. Tools lack guidance on tool ordering (e.g., 'always call get-tables or get-table-schema before get-table-data to understand structure'). No output field mapping shown, if get-table-data returns IDs, no documentation shows how to use them in follow-up calls.
Irreversible operations (call-stored-procedure, call-stored-function) lack confirmation or dry-run semantics. No indication whether calling these is idempotent or has side effects. LLMs may execute write operations without clear safeguards.
Credentials (DREAMFACTORY_URL, DREAMFACTORY_API_KEY) are environment variables, which is correct, but no documentation confirms this in tool code or README. LLMs may incorrectly infer that credentials should be passed as parameters.
Document tool composition order in a README or inline: 'Recommended workflow: (1) get-tables() to explore, (2) get-table-schema(tableName) to understand columns, (3) get-table-data(tableName) to retrieve rows.'
For the 'continue' parameter in get-table-data, clarify its purpose: 'In batch operations, continue processing remaining items even if one fails. Without this flag, processing stops at the first error. Returns per-item success/failure indicators.'
Add minimum/maximum bounds to numeric parameters: 'offset: minimum 0, default 0; limit: minimum 1, maximum 1000, default 10. Passing limit>1000 returns an error.'
Ensure stored procedure/function names accept human-readable names or support a lookup step: 'If you don't know the exact stored procedure name, call get-stored-procedures() first to list available procedures and select by display name.'
Log detailed errors to stderr (not just console.error). Include request context: tool name, parameters, timestamp, HTTP status/response body from DreamFactory API. This aids debugging without leaking secrets.