MCP server for Vectorless — give AI agents access to structure-preserving document retrieval
Vectorless MCP demonstrates solid tool design with complete schemas, clear descriptions, and proper parameter typing. All 7 tools have explicit definitions with JSON Schema validation via Zod. Descriptions are substantive (100-250 chars, well above the 10-char minimum). Parameters include type constraints, enums, and defaults. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is basic (generic error scrubbing). Tool composition is strong: each tool has a single responsibility, and the get_tree → get_section → query workflow is well-designed. Missing: output schema documentation, recovery guidance in errors, and tool annotations (readOnlyHint/destructiveHint).
Permanently delete a document and all its sections. This action is irreversible.
Get metadata and processing status for a specific document. Returns the document ID, title, content type, status, byte size, and timestamps.
Fetch a single section with its FULL content. Use after inspecting the document tree to retrieve specific sections by ID. Returns the section title, summary, content, token count, and position in the tree.
Get the hierarchical document tree — the structural outline of the document. Returns sections with IDs, titles, summaries, depth, parent/child relationships, and token counts. Does NOT include full section content (use vectorless_get_section for that). Use this to understand document structure before querying or fetching specific sections.
Upload and ingest a document into Vectorless. Accepts a URL or base64-encoded file. Supported formats: PDF, DOCX, Markdown, HTML, plain text. The document is parsed into a hierarchical tree of sections with summaries. By default waits for processing to complete before returning.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nesting). Handlers return JSON but no schema is published to clients.
Error handling lacks recovery guidance. Errors are scrubbed for secrets but do not tell LLMs what to do next (retry, ask user, try alternative tool). Generic error responses waste agent reasoning.
Tool annotations missing. vectorless_delete_document is destructive but lacks destructiveHint. vectorless_list_documents and vectorless_get_* are read-only but lack readOnlyHint. Annotations help clients optimize caching and safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
List all documents in Vectorless with their processing status. Returns document IDs, titles, status (pending/parsing/summarizing/ready/failed), and metadata. Supports pagination and status filtering.
Query a document using natural language — an LLM navigates the document tree to find and return the most relevant sections with full content. Returns the retrieval strategy used, matched sections, time taken, and token usage/cost. This is the primary way to find information in a document.
vectorless_ingest_document accepts base64-encoded file content but does not validate format or size limits. LLMs could pass invalid base64 or multi-GB payloads, causing silent failures or timeouts.
vectorless_delete_document lacks confirmation or dry-run support. Irreversible operations should require explicit confirmation to prevent accidental data loss by agents.