Loading ToolBench
MCP server giving LLM agents a seven-verb API over papers, documents, code, personal state, patents, and cached web/Wolfram/YouTube tool calls — backed by PostgreSQL + pgvector
precis-mcp has 8 tools with minimal documentation. Tool names are verb-based (get, search, put, edit, delete, tag, link, more) which is good, but descriptions are extremely sparse (10-50 chars), most parameters lack descriptions entirely, and no input schemas are visible in the provided source. The 'put' tool has NO input parameters documented beyond 'kind', 'edit' and 'delete' have only an 'id' parameter with minimal context, and 'more' has an empty input schema. Output schemas are not documented. Error handling guidance is absent. This server exhibits the hallmarks of a minimal/stub implementation rather than production-grade tool definitions.
Delete a document or entity
Edit or modify an existing document or entity
Retrieve a document or entity by ID
Create relationships or links between entities
Retrieve additional results or continue a previous operation
Create or update a document or entity
Search for documents or entities matching a query
Add or manage tags on a document or entity
Descriptions critically short: most descriptions are 10-50 chars, below the 194-char baseline for production tools. 'Retrieve a document or entity by ID' (41 chars) and 'Search for documents or entities matching a query' (49 chars) lack context for when to use the tool or what it returns.
Input schemas missing or incomplete: 'put' tool lists 'kind' as parameter but no 'description' field visible for the 'kind' parameter. 'edit' and 'delete' only specify 'id' with minimal context. 'more' has empty input schema ({}). Per HARD SCORING RULES, tools with missing/incomplete schemas must score 0-30 on schema.
Parameter descriptions absent or minimal: 'kind' parameter in 'put' and 'search' has description 'The type of entity (optional)' but no enum, validation rules, or guidance on valid values. LLMs cannot infer valid inputs without explicit constraints or examples.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
Output schemas not documented: no tool specifies what fields it returns, data types, or structure. LLMs cannot plan downstream calls or extract required data without knowing response format.
Vague tool names reduce clarity: 'put' (create or update?), 'edit' (modify what?), 'more' (continue what operation?). These names do not clearly convey action or distinguish from similar tools.
Missing error handling guidance: no tool description explains what happens on failure, what errors are retryable, or what the LLM should do next. Critical for 'delete' (destructive) and 'put'/'edit' (state-changing).
Destructive operations lack confirmation or dry-run: 'delete' tool has no mention of confirmation, dry-run, or undo capability. Agents make mistakes, irreversible operations should support a confirmation step.
'more' tool is underspecified: empty input schema and vague description ('Retrieve additional results or continue a previous operation') do not explain what prior operation it continues or how pagination works.
Missing parameter type safety: 'id' and 'kind' are typed as strings but no validation rules, format constraints, or length limits are documented. LLMs can pass invalid values (empty strings, extremely long strings) without guidance.