Loading ToolBench
Atoms API MCP Server for managing knowledge bases via the Smallest.ai API
The server has 3 tools with basic Zod schemas and minimal descriptions. Naming follows verb_noun convention (listKnowledgeBases, createKnowledgeBase, getKnowledgeBase), which is good. However, descriptions are extremely brief (under 20 chars for all tools), parameter descriptions are missing entirely, and output schemas are completely undocumented. The tools lack error handling guidance for LLMs, no enum constraints despite mutable state, and no idempotency hints. Per the hard rules, descriptions under 20 chars cannot exceed 40 points. Parameter documentation is absent, which suppresses schema scores. The server registers tools explicitly via server.tool() with Zod schemas, so tool existence is verifiable (no inference penalty).
Create a new knowledge base
Get details of a specific knowledge base
List all knowledge bases
Tool descriptions are under 20 characters. 'List all knowledge bases', 'Create a new knowledge base', 'Get details of a specific knowledge base' are all bare imperative statements with no context for WHEN or WHY to use them. LLMs cannot determine whether to call these tools vs. similar alternatives without richer descriptions.
Parameters lack descriptions entirely. 'name' and 'description' in createKnowledgeBase have empty description fields. 'id' in getKnowledgeBase has empty description. This directly violates the pattern:tool-description baseline (100% of A+ tools have param descriptions).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
No output schema documentation. Tools return JSON objects with unspecified structure. listKnowledgeBases returns an array of knowledge bases, but the response schema (fields, types, required keys) is not documented anywhere. This blocks LLM reasoning about downstream tool calls.
Error handling does not guide LLM recovery. All three tools catch errors and return isError: true with a generic message. Per pattern:recovery-guide: 'Error responses must tell the LLM what to do next.' Errors like 'HTTP error! status: 401' tell the agent nothing, is this retryable? Should it ask the user for a new API key? Is the service down? The agent has no recovery path.
No idempotency hints. createKnowledgeBase is a write operation (side effect) with no idempotency declaration or dry-run option. Per pattern:command-tool and pattern:confirmation-request: destructive/write operations should declare idempotency or offer confirmation to prevent accidental duplicates if an agent retries on ambiguous failure. No hint in the description or schema.
API key exposed in config.ts as a plaintext constant. Per pattern:secret-injection: 'Credentials must never appear as tool parameters... Use server-side secret injection via environment variables or vault.' While the API key is not a parameter (good), it's hardcoded in config.ts rather than loaded from environment. If the repo is public, the key is compromised. This should be `process.env.SMALLEST_AI_API_KEY` with validation.
No result pagination or limits. listKnowledgeBases returns all knowledge bases without page/offset/limit. Per pattern:paginated-result: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.' If a user has thousands of knowledge bases, the response bloats the context window and wastes tokens. The baseline recommends cap ~20-50 results.
No permission checks. createKnowledgeBase and getKnowledgeBase do not verify the calling agent/user has authority to create or read knowledge bases. Per pattern:permission-gate: 'Gate destructive or sensitive tools behind permission checks.' While this server may have upstream auth (Bearer token), the MCP server itself does not declare required permissions or check authorization.