Loading ToolBench
Type-safe 3rd party integration SDK for the Integrate MCP server
This is a TypeScript SDK for the Integrate MCP server, not an MCP server itself. It provides 9 tools with generally adequate naming (verb_noun patterns) and documented schemas, but has significant gaps in parameter descriptions, output schemas, and error handling guidance. Tool names are clear (trigger_*, execute_code, get_integration_types) but descriptions vary in quality and completeness. Most parameters have type definitions but lack detailed constraint documentation. The execute_code tool is particularly underdescribed relative to its risk level (arbitrary JS execution). No evidence of input validation, error recovery guidance, or per-tool output schema documentation.
Write an async JS/TS snippet that runs in an isolated sandbox. Chain multiple operations in one snippet using await, return <value> for JSON output, console.log() for debug. Each method returns ToolResult { content: [{ type, text? }], isError? } — parse result.content[0].text as JSON. Only client, callTool, fetch, console, JSON are available (no npm imports).
Get full parameter types for a specific integration before writing code
Schedule a tool to run at a specific time or on a recurring schedule. Use this when the user wants to do something later.
Delete a trigger permanently. This cannot be undone.
Get details of a specific trigger by its ID
List all scheduled triggers with optional filtering by status or tool name
execute_code tool has dangerously vague description for a sandbox execution primitive. Description mentions 'isolated sandbox' and available APIs (client, callTool, fetch, console, JSON) but does NOT clearly state: (1) execution is synchronous or async, (2) maximum timeout, (3) memory/CPU limits, (4) error handling behavior, (5) how to pass context to code. LLM may misuse tool or assume capabilities that don't exist.
No output schemas documented for any tool. LLMs need to know what fields to expect from each response to plan downstream tool calls. For example, trigger_create should document whether it returns {triggerId, name, status, createdAt, ...}; trigger_list should document the shape of trigger objects and whether it returns {triggers: [...], total, nextCursor, ...}.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2025-06-18+ | v2 |
| 2026-03-09 | C | 62 | - | v1 |
Pause a trigger to temporarily stop it from executing. Can be resumed later.
Resume a paused trigger to start executing it again on schedule
Update a trigger's properties like name, description, arguments, or schedule
trigger_list has limit and offset parameters but no documentation of default values, minimum/maximum bounds, or what 'limit' means (returned items? API call items?). No indication of whether pagination is supported or what the max page size is.
trigger_update's description does not explain which fields are optional vs required. The schema shows triggerId as required, but are name, description, toolArguments, and schedule all optional? Undocumented optionality leads LLMs to pass invalid combinations.
execute_code description includes example code syntax (await, console.log, return) but does NOT document: (1) what happens if code throws an error, (2) how errors are returned to the caller, (3) timeout behavior, (4) how to parse the ToolResult.content structure. This is a critical gap for a code execution tool.
No error handling guidance across any tool. Descriptions do not explain failure modes: What happens if a trigger with the given ID doesn't exist? How should the LLM handle a 404 vs a permission denied vs a network timeout? No recovery hints provided.
execute_code's schema does not specify additionalProperties=false correctly to prevent LLM from inventing parameters. Code parameter has no format validation (is length limited? charset limited?). Schema should declare max length and character constraints.
trigger_create's schedule parameter uses a union type (oneOf) with two object types (once vs cron), but does NOT document in the description what runAt format is expected for 'once' type (ISO 8601? Unix timestamp?) or what cron expression dialect is supported (POSIX cron? Quartz? Limited fields?).
No indication of which tools are idempotent vs state-altering. trigger_create is clearly WRITE; trigger_list is READ_ONLY; but does calling trigger_resume twice cause an error, succeed silently, or have undefined behavior? LLM retry logic depends on understanding idempotency.