Loading ToolBench
MCP server for Subindex — generate, validate, and fact-check research tables with AI
This is a moderately mature MCP server with 15 tools covering a cohesive domain (data validation, fact-checking, research table generation). Strengths: all tools have descriptions (50 - 200 chars, well-written); input schemas are visible and mostly complete; tool names follow verb_noun patterns (get_, create_, start_, upload_, wait_for_, send_, etc.). Critical weaknesses: (1) **Output schemas are largely undocumented**, no tool shows expected response structure, field types, or pagination info. The rubric requires documented output schemas for LLMs to plan downstream calls. (2) **Parameters often lack descriptions**, e.g., upload_file's file_path and file_type have descriptions, but no type validation is visible in the schema; session_id appears in multiple tools with only one-line descriptions lacking context on how to obtain it. (3) **Error handling and recovery guidance is absent**, no tool description explains failure modes, retryability, or what the agent should do if a job times out or a file upload fails. (4) **No tool annotations**, tools like approve_validation (which charges credits) and delete-like operations lack readOnlyHint, destructiveHint, or idempotentHint markers. (5) **Parameter relationships undocumented**, e.g., start_table_validation accepts both s3_key (from upload) and instructions (inline), but the description doesn't clarify which takes precedence or if both are required. Per-tool average: ~52/100.
Approve and trigger full validation (charges credits based on row count and columns)
Create a validation job from a configuration
Download and parse table_metadata.json from a presigned S3 URL (AI-readable results)
Get account balance and usage statistics
Fetch the inline preview table (markdown) from a job
Fetch download URLs and metadata for a completed job
Refine validation config with natural language instructions mid-interview
Output schemas are completely undocumented. No tool shows what fields are returned, their types, or structure. LLMs cannot plan downstream calls or extract chaining IDs (e.g., job_id from create_job, conversation_id from start_table_maker) without guessing.
Many parameters lack descriptions or have minimal ones. session_id, s3_key, conversation_id, and job_id appear across multiple tools with only generic one-line descriptions ('Session ID from upload_file'). LLMs need context: how to obtain it, whether it's required, what happens if it's missing.
No error handling or recovery guidance. Tools like wait_for_job (polling with timeout) and approve_validation (charges credits) lack descriptions of failure modes, what to do on timeout, partial failure, or insufficient credits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Send a message to an ongoing conversation (reply to AI question)
Start a reference check (fact-checking) job on text or uploaded document
Start a Table Maker conversation to generate a new research table from natural language
Start table validation on an uploaded file with optional instructions
Re-validate a completed table with the same configuration (after analyst corrections)
Upload a file (Excel, CSV, or PDF) to S3 for validation or reference checking
Poll a conversation until user reply is needed or execution is triggered
Poll a job until it reaches a terminal status (preview_complete, completed, or failed)
Parameter relationships undocumented. start_table_validation accepts both s3_key (from upload) and instructions (inline), but the description doesn't clarify mutual exclusivity, precedence, or whether both together are invalid. start_reference_check accepts both text and s3_key, unclear if both can be passed.
Destructive and state-changing operations lack annotations. approve_validation charges credits; update_table re-validates and may incur costs; send_conversation_message advances a workflow. No tool has destructiveHint, idempotentHint, or readOnlyHint markers to warn agents of side effects.
Polling tools (wait_for_job, wait_for_conversation) lack guidance on timeout behavior. No description of what happens if expected_seconds exceeds timeout_seconds, whether the job is still running, or if the LLM should retry with a different timeout.
No pagination or result-limiting guidance. Tools like get_results and fetch_table_metadata may return large objects or lists (metadata, download URLs, validation results). No mention of max result size, pagination, or truncation behavior.
Session/conversation lifecycle not documented. Tools reference session_id and conversation_id but don't explain: How long are sessions valid? Can an old session_id be reused? What closes a session? Can two concurrent conversations use the same session?