Loading ToolBench
Model Context Protocol server for Boomi integration platform, providing tools for managing trading partners, connectors, components, integrations, and API interactions with optional knowledge base support
The Boomi MCP server has 3 tools with significant quality gaps. All three tools have reasonable names starting with action verbs (get_, invoke_, index_) and descriptions present. However, the schema definitions are incomplete, only high-level parameter names and basic descriptions are visible; parameter types are not explicitly declared in the source. The invoke_api tool is particularly problematic: it accepts a generic 'payload' object with no schema constraints, violating the constrained-input pattern. Error handling details are not visible in the source excerpt. The server uses fastmcp framework with HTTP transport (positive), but tool annotation features (readOnlyHint, destructiveHint, idempotentHint) are not declared, and the overall schema documentation is sparse. Without seeing the full fastmcp registration code, tool definitions appear inferred rather than explicitly registered with complete schemas.
Self-documenting reference data for schema templates (no API calls) - returns templates for trading partners, connectors, and integration archetypes
Fetch a live profile component and return its normalized field index - read-only live existing-profile field indexing
Generic escape-hatch for any Boomi REST API endpoint
invoke_api accepts a generic 'payload' object parameter with no schema constraints, no enum validation, and no structural requirements. This violates the constrained-input pattern and invites hallucinated or malformed API payloads from LLMs.
Parameter types are not explicitly declared in visible source code. Schema definitions show only parameter names and descriptions, not JSON Schema type declarations (type: 'string', type: 'boolean', type: 'object'). This violates the pattern:tool-description baseline where 100% of A+ tools have fully typed parameters.
Tool annotation hints (readOnlyHint, destructiveHint, idempotentHint) are not declared. Risk metadata is known (invoke_api marked WRITE; get_schema_template_action and index_profile_component marked READ_ONLY in the context), but these are not encoded in tool definitions as machine-readable hints per the current spec (2026-07-28).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Output schemas are not documented in visible source. For invoke_api especially, what structure does the response return? Object? Array? What fields? Without documented return types, LLMs cannot plan downstream tool calls or extract data reliably.
invoke_api is a generic escape hatch that accepts any REST endpoint and method. While flexibility has value, this violates the single-responsibility principle (pattern:tool). A generic invoker makes it hard for LLMs to reason about what operations are safe, which are idempotent, and what error recovery looks like.
No error handling guidance visible. When invoke_api receives a malformed endpoint or the Boomi API returns an error, what error message and recovery hint does the tool provide? Agents need actionable errors, not raw HTTP status codes.
The include_raw_xml boolean parameter in index_profile_component lacks a range or default value definition. Is it required? Optional with default false? This ambiguity forces LLMs to guess.