Loading ToolBench
Exposes a Skalex document database as an MCP server for AI agents. Provides tools for querying, inserting, updating, and deleting documents, with support for semantic search and natural-language queries.
Skalex MCP server exposes 8 database tools with complete JSON schemas and descriptions. All tools have proper input schemas with typed parameters and descriptions. However, descriptions are brief (10-50 chars), falling below the 50-200 char baseline for LLM-optimized docs. Output schemas are not documented. Error handling guidance is absent. Tool naming follows verb_noun convention (skalex_find, skalex_insert) but lacks clarity on scope distinctions, 'skalex_search' vs 'skalex_ask' both query but differ in mechanism (semantic vs NL→filter), which is not obvious from names alone. No tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). Parameter descriptions are minimal; e.g., 'filter' is described as 'Query filter (MongoDB-style operators supported)' but does not explain depth limits, operator whitelist, or injection risks.
Translate a natural-language question into a filter and query a collection. Requires a language model adapter.
List all collection names in the database.
Delete the first document matching a filter.
Find documents in a collection that match a filter.
Insert a single document into a collection.
Return the schema for a collection as a { field: type } map. Returns null if the collection is empty.
Semantic similarity search. Requires an embedding adapter to be configured.
Descriptions are too brief (10-50 chars vs 50-200 char baseline). LLMs cannot determine when to select skalex_search vs skalex_ask, or understand prerequisites (embedding/LLM adapters required). Descriptions lack WHAT, WHEN, and RETURN guidance.
No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., does skalex_find return document IDs for use in skalex_update?). Violates pattern:tool requirement.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification in metadata (READ_ONLY, WRITE, DESTRUCTIVE). Agents cannot infer safety/retry semantics without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Update the first document matching a filter.
Parameter descriptions lack actionable constraints. 'filter' does not explain MongoDB operator whitelist, depth limits (MAX_FILTER_DEPTH=16), or injection risks. 'doc' in skalex_insert lacks schema guidance. Violates pattern:constrained-input.
skalex_search and skalex_ask lack prerequisite documentation. Both require adapters (embedding, LLM) but descriptions do not state this. Agents may call them without configuration and receive cryptic errors.