Loading ToolBench
MCP server for Ampersand AI SDK that provides tools for connecting to SaaS platforms, managing OAuth flows, and performing read/write operations on provider APIs
This MCP server exposes 8 tools for Ampersand AI integration (OAuth, connection management, API calls, record CRUD). Tool definitions have inconsistent quality. Most tools have clear descriptions (50-150 chars, within the baseline 194 avg), and all declare input parameters with type and description. However, critical gaps exist: (1) NO output schemas are documented anywhere in the tool definitions, LLMs cannot predict return types and will struggle with downstream data extraction; (2) NO error handling guidance, tools return responses but no documentation on failure modes or recovery paths; (3) Parameter descriptions contain example values ('e.g. monday, hubspot, salesforce') which LLMs tend to reuse literally; (4) No tool annotations (readOnlyHint, destructiveHint) despite clear WRITE vs READ_ONLY risk markings in the input data; (5) send-request and send-read-request have vague endpoints ('without the base URL...') with format details in descriptions rather than structured constraints. The tools themselves follow verb_noun naming (check-*, create-*, send-*, update-*), which is good. Schema quality varies: some params have enums (type field in create-record/update-record), others are free-form strings accepting provider names with no validation enum. This server lands in the C range, definitions are present and partially structured but lack the rigor expected for production agent toolkits.
Check if there is an active connection for provider
Check if there is an active installation for provider
Create a new installation for provider
Create a record in a SaaS platform (e.g. create a new Contact in Salesforce)
Call provider APIs via the Ampersand sendReadRequest tool
Call provider APIs via the Ampersand sendRequest tool
Connect to a SaaS tool provider using the Ampersand OAuth flow. The tool will return a clickable link to the OAuth flow for the user to click.
NO documented output schemas for any tool. LLMs cannot predict return types, field names, or structures. This forces agents to probe responses at runtime and increases hallucination risk when chaining tool calls.
Parameter descriptions embed example values ('e.g. monday, hubspot, salesforce'). LLMs frequently reuse examples literally rather than adapting to context, causing hardcoded provider names in real calls. Replace with enum constraints.
No error handling guidance. Tool descriptions do not explain failure modes (e.g. 'provider not found', 'invalid OAuth state', 'API call rate limited') or recovery paths. Agents have no actionable guidance on retries or fallbacks.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 57 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Update a record in a SaaS platform (e.g. update a contact's email address in Hubspot)
No tool annotations despite clear WRITE vs READ_ONLY semantics visible in input data. Tools like create-record, update-record, send-request, create-installation should declare destructiveHint=true. Tools like check-connection and send-read-request should declare readOnlyHint=true. This metadata helps agents reason about safety and side effects.
'provider' parameter accepts free-form strings with no enum constraint. Description says 'Always use camelCase (e.g. monday, hubspot, salesforce)' but does not enumerate valid values. LLMs will hallucinate provider names not supported by the server. Add an enum: ['monday', 'hubspot', 'salesforce', ...].
send-request and send-read-request have vague endpoint parameter descriptions ('without the base URL', 'full path after the instance URL'). Format expectations are buried in prose, not declared as structured constraints. LLMs will guess wrong on endpoint formats. Clarify with examples as enum or pattern constraint.
create-installation and send-request have optional parameters (groupRef, headers, providerWorkspaceRef) but lack clarity on defaults or when they are required. 'groupRef' appears in both create-installation and create-record, relationship is undocumented. Parameter dependency rules not stated.
'record' parameter in create-record and update-record is typed as 'object' with no field schema. LLMs cannot know what fields to include. Should provide a schema or list of valid field names per objectName.