Loading ToolBench
Laravel Telescope-style debugging for Hono, with an MCP server so AI coding agents can read your app's live requests, exceptions and queries. Zero runtime dependencies.
hono-telescope provides 5 well-defined diagnostic tools for Hono application observability. All tools have clear, action-oriented names (recent_exceptions, recent_requests, request_detail, slow_queries, stats), explicit input schemas with proper JSON Schema structure, and descriptions ranging 180 - 340 characters that explain WHAT the tool does and WHEN to use it. All parameters are typed and described. Tool annotations (readOnlyHint) are present and correct. The main limitations are: (1) output schemas are not explicitly documented in the source code, they exist implicitly in the tool implementation but are not visible in the tool definition structure, and (2) some parameter descriptions could include more guidance on how to chain tools together (e.g., 'Use request_detail on the request_id returned from recent_requests'). Error handling is not visible in the definition layer. Overall, this is a well-crafted diagnostic toolkit with good naming, descriptions, and schemas, but lacks explicit output documentation and recovery guidance.
The most recent exceptions, each with the request that produced it and that request's logs, queries and outgoing calls. Start here when something failed.
Recent incoming requests with child counts. Filter with minStatus: 400 to find failures that returned an error status without throwing.
One request in full — headers, payload, response body — with every log, query, exception and outgoing call recorded inside it. Nothing is truncated. Reach for it once a list tool has narrowed the search to one request.
Recent database queries sorted slowest first, each with the request it ran in. Use request_detail on that request to see everything else it did.
How many entries of each type Telescope is holding right now. The counts cover what is still retained: the oldest entries are dropped once storage reaches maxEntries. Read it first to see whether there is anything to look at, then drill in with recent_exceptions or recent_requests.
Output schemas not documented in tool definitions. While the tools clearly return structured data (exceptions with request details, requests with child counts, queries with performance metrics), the ToolDefinition interface does not include an outputSchema field, and the source does not show explicit response documentation. LLMs cannot plan multi-step chains without knowing what fields each tool returns (e.g., does recent_requests return 'request_id' or 'id'? does slow_queries return 'duration_ms' or 'duration_milliseconds'?).
Limited error recovery guidance in descriptions. The tool descriptions explain WHAT each tool does and WHEN to use it, but do not provide guidance on what to do if a tool call fails or returns no results. E.g., recent_exceptions says 'Start here when something failed' but does not explain what to do if the exception list is empty or if the request_id is not found in request_detail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 81 | 2025-06-18+ | v2 |
Tool chaining hints are implicit, not explicit. The description for recent_requests mentions filtering with minStatus and minDuration, and request_detail references 'the id of a recent_requests result', but a clearer chain-of-thought hint would help LLMs plan multi-step debugging: 'Call this first to get a list of request IDs, then pass one to request_detail for full details.'
stats tool has a generic name that does not start with a clear action verb. 'stats' is ambiguous, does it return statistics, configurations, or something else? A verb-noun name like 'get_stats' or 'list_metrics' would be clearer. The description does clarify the purpose ('How many entries of each type Telescope is holding right now'), but the name alone is weaker than verb-based alternatives.