Loading ToolBench
MCP server for VantagePeers — shared memory, messaging, and task coordination for AI agent teams
VantagePeers exposes 33 tools with consistent naming (verb_noun pattern) and structured schemas. However, critical gaps undermine production readiness: (1) Parameter descriptions are often vague or incomplete, many lack format/constraint details. (2) Output schemas are not documented in the provided source; LLMs cannot predict response structure. (3) Error handling is absent, no recovery guidance or actionable error messages visible. (4) Several parameter descriptions contain placeholder text ('Invalid memory ID format') rather than actionable guidance. (5) No tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). Naming is strong (list_*, get_*, create_*, update_*, delete_* follow conventions), but descriptions average ~80 chars, below the 194-char baseline for A+ tools. Schemas are present but lack depth.
Create a new diary entry with content and metadata
Create a new episode with title and description
Create a new mandate with title and scope
Create a new memory entry with content and metadata
Create a new task with title, description, and assignment
Delete a diary entry by ID
Delete an episode by ID
Placeholder parameter descriptions: 'Invalid memory ID format (expected 32-char Convex ID)' appears in get_memory, update_memory, delete_memory, get_task, update_task, delete_task, get_diary, update_diary_entry, delete_diary_entry, get_episode, update_episode, delete_episode, get_mandate, update_mandate, delete_mandate. These are error messages, not parameter guidance. LLMs cannot infer what value to pass.
Output schemas not documented. No visible response structure for any tool. LLMs cannot predict what fields to extract or chain downstream tool calls. E.g., does list_memories return {items: [], total: number, cursor: string} or {memories: [], count: number}?
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Delete a mandate by ID
Delete a memory by ID
Delete a task by ID
Export data as an OKF (Open Knowledge Format) bundle
Retrieve a single diary entry by ID
Retrieve a single episode by ID
Retrieve a single mandate by ID
Retrieve a single memory by ID with full details
Retrieve a single message by ID
Retrieve a single task by ID with full details
Import data from an OKF (Open Knowledge Format) bundle
Ingest documents into the knowledge base with vector embeddings
List diary entries with optional filtering by date range and namespace
List episodes with optional filtering by status and namespace
List mandates with optional filtering by status and assignee
List memories with optional filtering by type, namespace, and search terms
List messages with optional filtering by conversation, sender, and status
List tasks with filtering by status, assignee, project, and other criteria
Search the knowledge base with vector similarity and full-text search
Send a message to a conversation or recipient
Update an existing diary entry
Update an existing episode
Update an existing mandate
Update an existing memory's content and metadata
Update an existing task's properties
Validate an OKF (Open Knowledge Format) bundle for correctness
No error handling guidance. Tools declare Risk levels (READ_ONLY, WRITE, DESTRUCTIVE) but provide no recovery hints. If delete_memory fails, what should the LLM do? Retry? Ask the user? No guidance visible.
No tool annotations despite clear risk stratification. Tools marked DESTRUCTIVE (delete_*) should carry destructiveHint=true; READ_ONLY tools should carry readOnlyHint=true. This enables safer agent planning and audit trails.
Vague parameter descriptions. 'Filter by namespace', 'Filter by status', 'Filter by assignee' lack actionable detail. What format is namespace? Is status an enum or free-form? What identifier does assignee expect (ID, email, name)?