Loading ToolBench
ContextMore is a tool that allows you to embed documents and search them using a vector database. It is designed to be used in conjunction with the ContextMore MCP server.
ContextMore API MCP has two well-named tools with detailed descriptions and complete input schemas. Naming follows verb_noun conventions (embed_document, retrieve_documents). Descriptions are comprehensive (100-180 chars) and explain the operation, use case, and behavior clearly. Input parameters have types and descriptions. However, output schemas are not explicitly documented in the source code, only inferred from the response construction in app/main.py. Parameter descriptions are present but lack explicit constraints (e.g., top_k default/range, chunk formats). Error handling returns HTTPException with detail messages but lacks actionable recovery guidance per the pattern:recovery-guide rubric. No security-specific documentation (authentication is mentioned in embed_document but not formalized as scope declarations). Tool composition is good, two focused, single-responsibility tools. Overall, the tools are production-usable but lack the rigor of A-grade tooling.
Extracts text from a URL, chunks it, generates embeddings, and stores them in a vector database. Supports authentication via custom headers or basic auth. Updates existing documents if the URL already exists.
Generates an embedding for a query and searches the vector database for similar documents. Can group results by document or return individual chunks. Returns top-k most relevant results ranked by similarity score.
Output schemas not documented. While app/main.py shows the actual response structure (message, doc_id, call_name, date, is_update for embed_document; results array with doc_id, url, chunks, score for retrieve_documents), the response structure is not formally declared or visible to MCP clients. LLMs cannot plan downstream operations without knowing the response schema.
Parameters lack explicit constraints and defaults. top_k parameter description states 'default: 5' and 'group_by_doc' states 'default: true' in the description text, but these are not formally declared in JSON Schema (e.g., no 'default' field, no 'minimum'/'maximum' bounds). LLMs cannot validate inputs reliably without formal constraints.
Error handling returns generic HTTPException with detail messages but does not categorize errors as retryable, user-fixable, or fatal. A call with a malformed URL or failed text extraction returns a 400/500 error with a string message. The LLM has no guidance on whether to retry, ask the user, or abort.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
No scope declarations or permission documentation. embed_document is a write operation (modifies vector DB) and retrieve_documents is read-only, but the tool definitions do not declare permissions (e.g., 'read:documents', 'write:documents'). This limits audit trails and least-privilege configurations.
Result limits not formalized. retrieve_documents multiplies top_k by 4 internally (query_embedding qdrant search with limit=top_k*4) but does not document why or cap the effective result count. Users expecting top_k results may be surprised by the 4x multiplication.