Loading ToolBench
MCP server for EOSL.ai — source-backed hardware end-of-life (EOL/EOSL) lookups by part number; every date links to the vendor's own bulletin.
Five well-named, read-only tools with clear descriptions (avg 180 chars, within 10 - 1024 baseline). All tools have explicit JSON Schema with typed parameters and descriptions. lookup_part, bulk_check, and get_family include detailed matching semantics and return structures. Error handling is implicit (found:false for misses) but lacks recovery guidance. No tool annotations (readOnlyHint, etc.). Output schemas are documented in descriptions but not in formal response type declarations. Naming follows verb_noun pattern (lookup_, get_, bulk_, search_, list_) and is unambiguous. Parameters are well-constrained (part_number, vendor, family_slug, query). No secrets exposed. Composition is clean, each tool has one responsibility, and tools chain naturally (lookup_part → get_family, search_models → get_family).
Look up many part numbers at once (up to 200 per call). Returns an array of results, one per input part, in the same order. Each result has the same structure as lookup_part. Useful for inventory audits or batch lifecycle checks.
Fetch every part number in a product family, with their individual dates. Useful after lookup_part returns matchedVia:family-name, or when you know the family name but not the exact SKU. Returns an array of parts with their status, End-of-Sale, End-of-Service-Life dates, and source URLs.
List all vendors in the EOSL.ai database. Returns an array of vendor names. Useful for validating a vendor name before calling lookup_part or search_models.
Look up one hardware part number or model name in the EOSL.ai database (read-only, no auth; for many parts use bulk_check). Returns support status, End-of-Sale and End-of-Service-Life dates, support runway score, and the primary vendor bulletin URL backing the dates. Matching is exact, then punctuation-insensitive, then Fortinet short-SKU aliases (FG-60E -> FortiGate-60E); a model/family name (e.g. "7010TX-48") that matches no SKU returns the family-level record, flagged matchedVia:family-name. Anything else returns found:false rather than a guessed date.
Search for product families by name or keyword. Returns matching families with their vendor, status, and family slug (for use with get_family). Useful when you know a product name but not the exact part number.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All five tools are read-only and idempotent, but this is not declared in the tool definition. LLMs cannot infer safety properties without explicit hints.
Error handling lacks recovery guidance. lookup_part returns found:false for misses, but does not suggest next steps (e.g., 'Try search_models() with a partial name'). Agents cannot self-correct without explicit hints.
Output schemas are documented in prose descriptions but not formally declared as response types in the tool definition. LLMs cannot parse unstructured descriptions to infer return field names and types reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
list_vendors has minimal description (70 chars). While adequate, it lacks context on when to call it (e.g., 'Call before lookup_part to validate vendor names') and what structure it returns.
bulk_check accepts up to 200 parts but does not document per-item error handling. If 5 of 200 parts fail, does the tool return partial results or a blanket error? Ambiguity forces agents to retry everything.