Loading ToolBench
graip-mcp demonstrates solid definition quality with clear verb-based naming, detailed tool descriptions, and properly structured schemas. All 7 tools follow consistent patterns. Descriptions are comprehensive (100-200+ chars), parameter descriptions are present and specific, and input schemas use Zod validation. However, output schemas are not formally documented, error handling could be more recovery-focused, and tool annotations (readOnlyHint, destructiveHint) are missing. The server correctly separates concerns (add-flow, remove-flow, list-flows, extract-from-url, extract-from-base64, get-extraction, list-extractions) and uses natural identifiers (flow names, request IDs). Schemas show proper type constraints but lack explicit JSON Schema documentation in descriptions.
Register a named flow so you can reference it by name when extracting documents. For example, add a flow named "invoices" for invoice processing and "po" for purchase orders. The flow ID can be found at the end of the URL when a flow is selected in Graip.AI. Flows are saved per user and persist across sessions.
Process a base64-encoded document using a Graip.AI flow. Useful for documents you already have in memory or as base64 strings.
Process a document at a given URL using a Graip.AI flow. The document is downloaded, sent to Graip.AI for processing, and the extracted data is returned.
Retrieve the result of a document extraction by request ID.
List all extraction requests submitted by the current user, with their status and timestamps.
List all configured flows for the current user.
Output schemas are not formally documented. While tool descriptions describe what they return conceptually (e.g., 'the extracted data is returned'), the actual structure of responses (fields, types, pagination) is not declared. LLMs cannot plan downstream calls or extract specific fields without seeing the response schema.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent. The server correctly identifies write operations (add-flow, remove-flow are WRITE; others are READ_ONLY), but these are not communicated via the protocol with tool annotations. LLMs cannot reliably infer which tools are safe to retry.
Error responses lack recovery guidance. While the code validates extensions, API keys, and flow names, error messages do not consistently tell the LLM what to do next. E.g., 'Flow not found' includes available flows, but other errors like 'Graip API error (400)' do not guide recovery.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-04-07 | F | 23 | - | v1 |
Remove a previously configured flow by name.
Pagination is not implemented for list tools. list-flows and list-extractions have empty input schemas and no documented limit, offset, or cursor parameters. If users accumulate many flows or extraction requests, unbounded results could exhaust the context window.
API key is exposed as a request header (Authorization header) rather than being injected via environment or MCP integration. The code does extract it from the request, but best practice is server-side secret injection so API keys never appear in tool calls.
Confirmation/dry-run pattern missing for destructive tools. remove-flow and add-flow (write operations) execute immediately without a confirmation step. Agents make mistakes, a dry-run or explicit confirmation would prevent accidental flow deletion.