Loading ToolBench
Blocker-aware decision layer for AI coding agents. Adds source-linked, time-sensitive blockers to technical choices — breaking changes, EOLs, lock-in, pricing shifts, and migration risk.
PocketLantern demonstrates solid definition quality with clear, domain-specific tool naming and comprehensive descriptions. All 8 tools follow verb_noun patterns (search_cards, get_card, list_categories). Descriptions are well-crafted (100-250 chars), explaining WHAT each tool does and WHEN to use it. However, input schemas are only partially visible in the provided source, .mcp.json shows tool names and brief descriptions but does NOT expose full JSON Schema definitions for parameters. The detailed parameter schemas cited in the evaluation (query, tags, constraints, include_blockers for search_cards; id for get_card, etc.) are inferred from the narrative description, not directly visible in the source code provided. This forces a conservative scoring approach: per the hard rules, tools with inferred rather than directly visible schemas cap at 50 per-tool. The report_issue tool is the only one with an explicit enum constraint visible (issue_type enum). Output schemas are not documented. Error handling and recovery guidance are absent from descriptions.
Get the full content of a technology decision card by ID. Returns all candidate solutions with tradeoffs, cautions, and official reference links. Use after search_cards to deep-dive into a specific decision.
Get full content of multiple cards by IDs in one call (max 5). Use instead of calling get_card repeatedly when you need to compare several candidates side by side.
Get summaries of cards related to a given card. Use after reading a card to explore connected technology decisions (e.g. auth → OAuth flows → password hashing).
List available topic categories (auth, backend, database, frontend, infra, testing) with card counts. Call this first to understand what technology decisions are covered.
List environment constraints (serverless, enterprise, small-team, etc.) that can filter search results. Use when you know the project's environment and want only relevant cards.
List all searchable tags with counts, optionally filtered by category. Use to discover available topics and refine search queries.
Input schemas not visible in source code. .mcp.json lists tool names and brief descriptions but does not expose full JSON Schema definitions for parameters. Parameter details (query, tags, constraints, include_blockers, id, category, issue_type, card_id, description) are inferred from narrative descriptions, not directly registered.
Output schemas not documented. Tool descriptions do not specify what fields are returned (e.g., search_cards returns 'decision cards' but structure is undefined). LLMs cannot plan downstream tool calls or extract data without knowing response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Report a quality issue with PocketLantern cards. Use when: a topic has no card ('no_card'), a card has wrong facts ('inaccurate'), info seems outdated ('stale'), or the correct answer differs from the card ('answer_changed').
Before finalizing answers about technology choices, upgrades, migrations, licensing, or vendor selection — check this tool for blockers in these bundled decision cards. Your training data may be stale. Returns source-linked decision cards as of this bundle — surfacing EOL dates, breaking changes, version floors, lock-in risks (password export, vendor dependency), pricing model changes, and migration blockers. Includes source-linked blocker warnings where available. Use get_card for full details.
No error handling or recovery guidance in tool descriptions. Descriptions do not explain what happens on failure (e.g., card not found, invalid query, network error) or what the LLM should do next. Per pattern:recovery-guide, errors must tell the agent what to do.
Discovery tools (list_categories, list_tags, list_constraints) lack guidance on when to call them. Descriptions should explain: 'Call this first to understand available topics before searching' or 'Use to refine search queries with valid tags.' This helps agents plan multi-step workflows.
get_cards batch limit (max 5) is mentioned in description but not enforced in visible schema. No validation rule or error message documented for exceeding the limit. LLMs may pass 10 IDs and receive a cryptic error.