Loading ToolBench
AI-driven MCP server that scaffolds, configures, and deploys end-to-end Ballerina + Salesforce integrations in a WSO2 Integrator (BI) workspace — 18 tools, from OAuth to a running REST service.
Server has 18 well-structured tools with complete Zod schemas and descriptions. Naming follows verb_noun convention (sf_get_*, sf_list_*, sf_describe_*, sf_scaffold_*, sf_deploy_*, etc.). All tools have descriptions (10 - 200 chars, within baseline). Parameters are typed and described. However, several tools expose credentials (sf_client_id, sf_client_secret, sf_refresh_token) as parameters, a critical security anti-pattern. Output schemas are not documented in the source. Error handling is present but generic. Some parameter descriptions could be more actionable (e.g., cdc_listeners lacks detail on structure). Tool composition is sound: tools chain logically (OAuth → validate → scaffold → deploy). Descriptions are clear but could be more LLM-optimized per pattern:tool-description baseline (50 - 200 chars ideal; many are 100 - 150, which is good).
Compile a Ballerina project to verify syntax and dependencies.
Start a Ballerina service in the background, with automatic token refresh and port conflict resolution.
Retrieve detailed metadata for a specific SObject, including all fields, relationships, and properties.
Exchange a Salesforce OAuth2 authorization code for access and refresh tokens.
Export a Postman collection to a JSON file.
Generate a Postman collection for testing the REST API endpoints of a Ballerina + Salesforce project.
Generate a Salesforce OAuth2 authorization URL for user login and consent.
Credentials exposed as tool parameters (sf_client_id, sf_client_secret, sf_refresh_token). These must be injected server-side via environment variables or vault. Agent traces log all parameters, secrets in params leak into logs and prompt history.
Output schemas not documented. Tools return results but the response structure is not visible in the source. LLMs cannot plan downstream calls or extract fields without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Retrieve the last N lines of logs from a running Ballerina service.
Obtain a Salesforce refresh token using username and password (Resource Owner Password Credentials flow).
List all Ballerina services currently running in the background.
List all SObjects (standard and custom) in a Salesforce org, with optional filtering and pagination.
One-shot setup: validate credentials, scaffold a project, optionally build it, and optionally start the service.
Read the contents of a file in a Ballerina project (e.g. main.bal, Config.toml).
Mint a fresh access token from a refresh token and update the project's Config.toml.
Generate a new Ballerina + Salesforce integration project with REST API and/or CDC listeners, ready to build and deploy.
Stop a running Ballerina service by PID.
Validate that Salesforce credentials are correct and the org is reachable.
Write or update a file in a Ballerina project.
cdc_listeners parameter (array of objects) lacks structural documentation. The schema shows it accepts an array but does not document the object shape (sobject, all_changes, platform_event, events fields). LLMs cannot construct valid payloads without this detail.
Error handling is generic. Tools do not return actionable recovery guidance (e.g., 'User not found. Try search_users() with a partial name.'). Agents receive errors but no next steps.
No pagination or result limits documented for sf_list_sobjects. The schema includes limit (max 200) and offset, but the description does not state the default or warn about large result sets.