Local-first shared context CLI for agentic tools with MCP server support
pluro-mcp defines 10 tools with explicit schemas and descriptions. Naming follows verb_noun convention (pluro_context_add, pluro_context_list, etc.), which is clear. However, parameter descriptions are sparse or missing entirely in the tool definitions shown. For example, pluro_context_list has properties like 'query', 'sourceTool', 'scope', 'tag', 'limit', 'cursor' with NO descriptions in the TOOL_DEFINITIONS array, only in the Zod schemas. The tool descriptions themselves are brief (10-50 chars) and lack actionable context about when to use each tool or what it returns. Error handling is present (toToolError function) but generic. Output schemas are not documented. Pagination is supported (limit, cursor) but not explained in descriptions. Security: no secrets in params (good), but no permission gates or audit trail hints visible.
Create a shared context entry in the local pluro store.
Delete one context entry by id.
Get one context entry by id.
List shared context entries with optional filters.
Inject one discovered conversation into the pluro store.
List conversations discovered by previous scans.
Scan local IDE roots and index discovered conversations.
Parameter descriptions missing in TOOL_DEFINITIONS. The inputSchema objects in TOOL_DEFINITIONS array lack descriptions for properties (e.g., pluro_context_list has 'query', 'sourceTool', 'scope', 'tag', 'limit', 'cursor' with no descriptions). Zod schemas have them, but LLMs read the MCP tool definitions, not internal validation code. This forces LLMs to guess parameter meaning.
Tool descriptions are too brief (10-50 chars) and lack actionable context. E.g., 'List shared context entries with optional filters' does not explain when to call this vs pluro_context_get, what the response structure is, or how pagination works. Descriptions should be 50-200 chars and answer: what, when, and what it returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2025-06-18+ | v2 |
List context history entries.
Export context entries as a structured snapshot payload.
Import a snapshot payload into the local context store.
Output schemas not documented. The toToolResult function returns JSON text and structuredContent, but there is no schema definition for what fields the LLM should expect from each tool. LLMs cannot plan downstream calls or extract data without knowing the response structure.
Error handling is generic. toToolError returns a simple text message with no guidance on recovery, retryability, or next steps. E.g., if pluro_context_get fails with 'not found', the LLM does not know whether to retry, call pluro_context_list to search, or give up.
Destructive operations (pluro_context_delete, pluro_snapshot_import with 'lww' policy) lack confirmation or dry-run support. An agent could accidentally delete all context entries. No confirmation_request pattern visible.