Loading ToolBench
A Model Context Protocol Server for One that enables integration with multiple platforms and actions through the One API
This server has well-structured tool definitions with strong naming conventions (all verb_noun style: list_, search_, get_, execute_), comprehensive parameter descriptions, and clear enum constraints. However, there are significant gaps in output schema documentation and error handling guidance. The schema score is held back by missing return type documentation and incomplete error response patterns. Descriptions are generally strong (100-200+ chars, LLM-optimized), but lack explicit recovery guidance for common failure modes. Parameter descriptions are thorough with constraints clearly stated.
Execute a One action to perform actual operations on third-party platforms. CRITICAL: Only call this when the user's intent is to EXECUTE an action (e.g., 'read my last Gmail email', 'fetch 5 contacts from HubSpot', 'create a task in Asana'). DO NOT call this when the user wants to BUILD or CREATE code/forms/applications - in those cases, stop after get_one_action_knowledge and provide implementation guidance instead. REQUIRED WORKFLOW: Must call get_one_action_knowledge first. If uncertain about execution intent or parameters, ask for confirmation before proceeding.
Get comprehensive documentation for a specific action including parameters, requirements, and usage examples. MANDATORY: You MUST call this tool before execute_one_action to understand the action's requirements, parameter structure, caveats, and proper usage. This loads the action documentation into context and is required for successful execution. Large documents come back as a digest (the sections needed to build a correct request, plus a list of what was omitted); request an omitted section by name with `section`, or the whole document with `full: true`.
List all available One integrations and platforms. ALWAYS call this tool first in any workflow to discover what platforms and connections are available. This returns the connections that the user has and all available One platforms in kebab-case format (e.g., 'ship-station', 'shopify') which you'll need for subsequent tool calls. Each connection carries an `access` field describing what you may run on it: `full`, a set of allowed HTTP `methods`, or a specific list of `actions` (each with `actionId`, `title`, `method`). When a connection is action-scoped, its `actions` are exactly what may run, so you need not search.
Output schemas are not explicitly documented in source code. Tool descriptions reference structured responses but no formal JSON Schema definitions are visible for return types. This forces LLMs to infer response structure from text descriptions, increasing hallucination risk.
Error handling lacks explicit recovery guidance. Descriptions warn about required prerequisites (e.g., 'You MUST call this tool before execute_one_action') but do not provide actionable error messages or fallback suggestions for common failure scenarios (e.g., invalid platform name, missing connection key).
execute_one_action has a complex input schema with many optional parameters (data, pathVariables, queryParams, headers, isFormData, isFormUrlEncoded) but lacks documentation on how these interact, which are mutually exclusive, and when each should be used. Parameter descriptions are minimal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2025-06-18+ | v2 |
Search for relevant actions on a specific platform using a query. Call this after list_one_integrations to find actions that match your intent. Returns the top 5 most relevant actions based on your search query. Use the exact kebab-case platform name from the integrations list.
The search_one_platform_actions tool accepts an 'agentType' enum parameter (execute|knowledge) but its impact on behavior is not clearly explained. Descriptions state it affects 'context' but do not specify what results differ, how filtering changes, or why an LLM should choose one over the other.
No pagination or result limit enforcement visible in parameter schemas. search_one_platform_actions claims to return 'top 5' results but no limit parameter is exposed, and no maximum result count is enforced in code. get_one_action_knowledge can return large documents but no explicit truncation or streaming mechanism is documented.