Loading ToolBench
MCP server that helps developers and AI agents explore and integrate the Toss Securities (토스증권) Open API.
This is a well-structured API documentation server with 9 discovery/navigation tools. All tools are clearly named with action verbs (get_, list_, search_), have substantive descriptions (100 - 250 chars), and parameter schemas are properly typed with Zod validation. The tool set is cohesive and follows the single-responsibility principle. However, there are gaps: (1) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only, should declare this explicitly. (2) Output schemas are not documented in the code, while the server returns text, the structure (e.g., what fields list_endpoints returns) is not formally specified. (3) Some parameter descriptions could be more prescriptive about valid values and constraints. The server excels at discovery-oriented tools and provides solid navigation between them, but lacks the polish of production-grade error handling and explicit schema declarations.
Generates ready-to-run code samples in curl, TypeScript, or Python for a specific endpoint. Includes example values, path substitution, auth headers, and usage notes.
START HERE. Returns a high-level map of the Toss Securities Open API: title, version, base server URL, the authentication model, and every category (tag group). Call this first to orient yourself, then drill down with `list_endpoints`, `get_endpoint`, or `get_integration_guide`.
Returns full detail for ONE endpoint: summary, description, auth requirement, parameters, request body schema, and response schemas with examples. Identify the endpoint either by `operationId` (preferred) or by both `method` and `path`.
Task-oriented integration walkthrough with step-by-step operationIds and conceptual overview. Guides available: authentication, market-data, account-and-assets, trading. Call `get_endpoint` on each step's operationId for full request/response schema.
Returns the field tree of one data model: field names, types, required fields, descriptions, and nested structures. Expand a schema first with `list_schemas` if you don't know the exact name.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared on any tools. All 9 tools are read-only, safe, and idempotent, this should be explicitly signaled to clients and agents for correct prioritization and batching.
Output schemas not formally documented. All tools return `text()` (a single text content block), but the internal structure (e.g., list_endpoints returns formatted markdown with endpoint summaries) is never declared. Clients cannot introspect response fields or validate shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Lists every API category (OpenAPI tag) with its display group, endpoint count, and description. Use the category name as the `category` argument of `list_endpoints`.
Lists endpoints as `METHOD path (operationId) — summary`. Pass `category` (an exact tag name from `list_categories`) to filter. Returns all endpoints when no filter is given. Use the operationId with `get_endpoint` for full detail.
Lists the data model (schema) names defined by the API. Pass `query` to filter by substring. Use a name with `get_schema` to see its fields.
Keyword search across operationId, path, summary, description and tags. Returns the best-matching endpoints ranked by relevance. Use this when you don't know the exact category or operationId. Example queries: 'place order', 'current price', 'holdings', 'exchange rate'.
Parameter descriptions lack prescriptive constraints. E.g., search_endpoints accepts 'limit' with no stated minimum/maximum. get_integration_guide accepts 'guideKey' but does not enumerate valid choices in the parameter description (only in tool description). Constraints should be in parameter descriptions, not just tool text.
No error recovery guidance. Tools can fail (e.g., operationId not found in get_endpoint, category filter mismatch in list_endpoints) but return minimal context. Error responses should suggest recovery steps (e.g., 'Category not found. Try list_categories() first.').
No pagination or limit enforcement on discovery tools. list_endpoints can return all 100+ endpoints in one response; list_categories and list_schemas have no stated limits. Large responses waste tokens and risk context exhaustion. Should cap results and offer pagination (offset/limit or cursor).