MCP server for interacting with Glide API v1 and v2
Server has 6 tools with complete input schemas and basic descriptions. However, descriptions are minimal (10-50 chars), lacking context on WHEN to use each tool or what happens on failure. Parameter descriptions exist but are terse. No output schemas documented. The 'values' parameter in add_table_row and update_table_row uses additionalProperties:true with no guidance on valid column names or types. Error handling exists (McpError wrapping) but lacks recovery guidance. Tool naming is clear (verb_noun pattern), but composition could be improved, set_api_version is a stateful operation that should ideally be handled via environment config or server initialization, not a tool call.
Add a new row to a table in a Glide app
Get information about a Glide app
Get rows from a table in a Glide app
Get tables for a Glide app
Set the Glide API version and authentication to use
Update an existing row in a table
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., appId, tableId) from responses. Baseline: 100% of A+ tools document return types.
Descriptions are 10 - 50 characters, below the 194-char baseline for production tools. They lack context on WHEN to use each tool, what it returns, or prerequisites. E.g., 'Get tables for a Glide app' does not explain whether this lists table metadata, row counts, or schema details.
'values' parameter in add_table_row and update_table_row uses additionalProperties:true with no schema or guidance. LLMs cannot infer valid column names, types, or constraints. Should document expected column structure or provide a discovery tool (e.g., get_table_schema).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
set_api_version is a stateful operation exposed as a tool. This violates the stateless request model, credentials should be injected server-side via environment variables or vault, not passed as tool parameters. Current design risks leaking API keys into logs and traces.
Error responses wrap Glide API errors in McpError but do not provide recovery guidance. E.g., 'Glide API error: Invalid app ID' tells the LLM nothing about what to do next. Should include suggestions like 'Try get_tables() to list available apps' or 'Verify appId format.'