Loading ToolBench
Wandering RAG CLI tool - A vector store and RAG system for managing memories and documents from Markdown, Notion, and other sources
wandering-rag provides two tools with reasonable descriptions and partial schema definitions. However, the tool naming violates critical verb_noun conventions (tools are prefixed with product name rather than action verbs), output schemas are not formally documented, and parameter descriptions lack specificity about formats and constraints. The server uses STDIO transport which is a significant limitation. Both tools are visible in source code with explicit registration via @mcp.tool decorators.
Look up memories in wandering-rag. Use this tool when you need to: - Find memories by their content - Access memories for further analysis - Get some personal information about the user - Answer questions about "my memory" or "my notes" You can search by specifying any of the following parameters: - query: The query to use for unstructured full-text search. It does NOT support logical operators like AND, OR, NOT. If not provided, the tool will scroll through the collection with the following filters instead. - doc_id: Retrieve chunks by its doc_id. - tag: Retrieve chunks with specified tag. - first_chunk_index: Retrieve chunks starting from this position. - created_before: Retrieve chunks created before this timestamp. - created_after: Retrieve chunks created after this timestamp. - last_modified_before: Retrieve chunks last modified before this timestamp - last_modified_after: Retrieve chunks last modified after this timestamp The tool will return a list of chunks, which have the following schema: - doc_id: Unique identifier for the document - title: Title of the document - source: Source type of the document (Markdown, Notion, etc.) - content: Text content of the document - chunk_index: Index of the chunk in the document - doc_url: URL to access the original document - source_url: Original URL if document was imported from a web source - tags: List of tags associated with the document - created_at: Timestamp when the document was created - last_modified_at: Timestamp when the document was last modified - extra_data: Additional metadata as key-value pairs Example usage: - Search by unstructured text like find anything about math or matrix: {query: "math matrix"} - Search by doc_id to retrieve chunks: {doc_id: "wandermyz-evernote/notes/2022-01-01"} - Search by tag: {tag: "math"} - Get more chunks from the same document: {doc_id:"<doc_id>", first_chunk_index:<n>} - Find notes within a specific time range: {created_before: "2023-01-01", created_after: "2021-01-01"} - Find notes last modified within a specific time range: {last_modified_before: "2023-01-01", last_modified_after: "2021-01-01"} When prompted with date related questions, remember to use the parameter of created_before, created_after, last_modified_before, last_modified_after. Do not put date in the query parameter, as the full text does not typically include date information. When answering questions, always include the raw doc_url of the note in the response. It might be a custom schema, not necessarily https. Convert any \u to their corresponding unicode characters. For example: - obsidian://open?vault=wandermyz-evernote&file=notes/矩阵 - Math.md - https://notion.so/1a2b3c4d
Tool names do not follow verb_noun convention; prefixed with product name instead of action verbs. 'wandering-rag-store' should be 'store_memory' or 'save_memory'; 'wandering-rag-find' should be 'search_memories' or 'find_memories'. LLMs infer action intent from the verb at position 0 and may struggle with ambiguous product-prefixed names.
Output schema not formally documented. wandering-rag-store returns a string; wandering-rag-find returns List[str] with XML-like tagged entries. The structure of returned entries (with <entry><content>...</content><metadata>...</metadata></entry> format) is mentioned in description but not in schema definition. Clients cannot parse or validate output without reading description text.
DateTime parameters lack format specification. created_before, created_after, last_modified_before, last_modified_after are typed as datetime objects in Python but descriptions do not specify ISO 8601 format or timezone handling. Agents may pass invalid datetime strings.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Keep the memory for later use, when you are asked to remember something.
Conditional parameter dependencies not documented. wandering-rag-find accepts either 'query' for full-text search OR filter parameters (doc_id, tag, created_before, etc.) for scrolling. This mutual exclusivity and the behavior difference (search vs. scroll) is not clearly documented in individual parameter descriptions.
Error handling is generic. Exception handler logs but returns raw exception without actionable recovery guidance. wandering-rag-find returns a generic 'No information found' message but does not suggest alternative search strategies or related queries the agent could try.
No pagination or result limiting explicitly declared in tool descriptions. wandering-rag-find has DEFAULT_QUERY_LIMIT and DEFAULT_QUERY_THRESHOLD constants used internally, but limits are not exposed in description or parameters. Agents cannot request fewer results or understand when they are hitting a limit.
Metadata parameter in wandering-rag-store lacks validation or structure guidance. Described as 'JSON metadata to store with the information, optional' but no schema for expected metadata structure, no constraints on depth/size, and no examples of valid metadata objects.