Loading ToolBench
A TypeScript MCP server implementation with multiple transport options (stdio, HTTP stream) and tool integration examples, including Notion API integration.
This repository is a learning/tutorial codebase ('mcp-typescript-deep-dive') containing 17 tool definitions scattered across multiple example servers, not a cohesive production MCP server. Tools have basic descriptions (average ~50 chars) and partial schemas. Many tools lack comprehensive parameter documentation, and several are duplicated across files (add, subtract appear 3 times each). The Notion API tools (post-search, get-a-page, patch-a-page, etc.) show better structure with explicit schema objects, but even these lack detailed parameter descriptions and don't document output schemas. Simple math/utility tools (get_weather, multiply, divide) have minimal descriptions. No tool has error recovery guidance, and no tools declare destructive hints despite PATCH/write operations. The codebase demonstrates patterns but does not meet production-grade quality standards.
add two numbers
Add two numbers
Add two numbers
Divide two numbers
Explain what kiro is
Get a page
Get the children of a block. Block can be a page, another block, or a child block.
Duplicate tool names (add, subtract appear 3 times each) across different files. LLMs cannot disambiguate between identically-named tools; this violates the single-responsibility principle and creates routing confusion.
Parameter descriptions are generic or missing. 'sort' and 'filter' in post-search are described only as 'Sort configuration' and 'Filter configuration' without explaining valid keys, structure, or constraints. LLMs cannot construct valid payloads without concrete guidance.
No output schemas documented. Tools return raw JSON responses without documenting structure, field types, pagination, or whether results are paginated. Agents cannot plan downstream calls or extract chaining IDs (e.g., page_id for follow-up block queries).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | 2025-06-18+ | v1 |
Get the current time in a given timezone
Get the current weather in a given location
Multiply two numbers
Patch a block
Patch a page
Search by title
Retrieve a block
Subtract two numbers
Subtract two numbers
test_experiment_3
Destructive write operations (patch-a-page, patch-a-block) lack error handling, confirmation patterns, or dry-run support. Tool descriptions do not warn that PATCH calls modify state irreversibly. No guidance on retryability or rollback.
Tool 'explain_kiro' has no visible input schema. The tool is registered but no schema parameter is provided, violating the requirement that every tool must have a schema. Score capped at 0 for schema dimension.
Tool 'test_experiment_3' has a trivial description ('test_experiment_3') that does not explain what the tool does, when to call it, or what it returns. Description is non-informative.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Write tools (patch-*) do not declare themselves as destructive, and idempotent tools (GET operations) do not declare idempotency. LLMs cannot infer retry safety or side effects.
Authtoken is passed as a server option during registration but not documented in tool descriptions. If an agent were to inspect what credentials are needed, it has no guidance. Best practice is to document required permissions/scopes in each tool's description.
Error responses return raw HTTP status text (response.statusText) with isError flag but no actionable guidance. A 401 returns 'Unauthorized' without suggesting 'Check your Notion API token' or retry guidance. Per the error-classification pattern, every error should tell the agent what to do next.