Loading ToolBench
MCP server for OEIS (Online Encyclopedia of Integer Sequences) sequences
This server has 3 tools with significant quality gaps. Tool naming is weak (non-verb-based), descriptions lack context and examples, input schemas are mostly empty or minimal, and there is no documented output schema. The find_by_id tool has a reasonable parameter description ('The OEIS sequence ID (e.g., A000045)'), but the other two tools have either no parameters or vague descriptions. The get_url tool has an empty input schema ({}), violating the requirement that all parameters be described. search_by_subsequence has a well-formed array parameter but lacks context about what the output structure looks like. No error handling guidance is documented. No tool annotations (readonly, destructive, idempotent hints) are present. The codebase shows proper Rust implementation with async/await and structured error handling, but the tool interface definitions exposed to the LLM are underdeveloped.
Find a sequence by its ID.
Get a URL of OEIS entry.
Search sequences by subsequence.
Tool names do not start with action verbs. 'get_url' is weak (what URL? what does it return?). 'find_by_id' uses 'find' instead of 'search' or 'get'. 'search_by_subsequence' is verbose. LLMs cannot infer intent from these names without reading descriptions, and similarity between 'get_url', 'find_by_id' causes confusion about which tool to use.
get_url has an empty input schema ({}). No parameters are described. The tool description says 'Get a URL of OEIS entry' but does not specify which entry, how to identify it (by ID? by sequence?), or what the output contains. LLMs cannot invoke this tool without guessing.
No output schema is documented for any tool. LLMs do not know what fields to expect in the response, what type each field is, or what data they can extract for downstream tool calls. This forces the LLM to infer structure at runtime, increasing errors and token waste.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Tool descriptions are generic and lack context. 'Find a sequence by its ID' does not explain what a sequence is, why an LLM would call this tool (vs search_by_subsequence), what the returned data looks like, or what to do if no match is found. Descriptions should be 50 - 200 characters and include WHAT, WHEN, and what the return type is.
No error handling guidance. If a user provides an invalid sequence ID, the tool will return an error, but the LLM is not told whether to retry, ask the user for clarification, or give up. No recovery paths are documented.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All three tools are read-only (do not modify state), but the LLM is not explicitly told this. Tool annotations enable the protocol to classify tools by safety profile, allowing agents to make better decisions about tool use.