Extract automations from an Airtable base via internal v0.3 API
Single tool 'extract' has a clear verb-noun name and adequate description (98 chars), but critical gaps undermine quality. Input schema is present with three parameters (base_id, output_dir, cookie), all with descriptions. However, the schema lacks type declarations visible in the MCP registration, only the raw Python function signature is evident. No output schema is documented. The tool accepts a raw cookie as a parameter, violating secret-injection patterns. No error handling guidance, no pagination, no structured output schema. The description does not explain what the tool returns or when to use it. This is a single-tool server with foundational issues.
Extract all automations from an Airtable base via internal v0.3 API
Cookie exposed as tool parameter violates secret-injection pattern. Credentials must never appear in tool parameters; use server-side secret injection via environment variables or vault. Agent traces log every parameter, secrets leak into logs.
No output schema documented. LLMs cannot plan downstream operations or extract returned data without knowing the structure. Tool description does not state what fields are returned or what the JSON output contains.
Input schema lacks explicit type declarations in MCP registration. Only Python function signature visible; no JSON Schema with 'type' fields for base_id, output_dir, cookie.
No error handling guidance. Tool exits with sys.exit(1) on 401, 4xx, or secret scan failures. LLM receives no recovery hints, should return structured error with actionable next steps (e.g., 'Cookie expired. Refresh from DevTools.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Tool description (98 chars) lacks context on when to use it, what it returns, and prerequisites. Does not explain that output is JSON files written to disk, or that cookie must be fresh. Baseline for A+ tools is 50-200 chars with WHAT/WHEN/RETURN clarity.