Loading ToolBench
Model Context Protocol server for Respond.io API integration with STDIO and HTTP/SSE support
The server provides 25 well-named tools with consistent verb_noun naming (create_contact, get_contact, list_messages, etc.). All tools have descriptions and input schemas are visible with type definitions. However, several critical gaps reduce the score: (1) Output schemas are not documented, responses are not visible in the source; (2) Parameter descriptions are present but often generic, lacking specifics about format, constraints, and ranges; (3) No error handling guidance in descriptions; (4) Missing examples of chaining IDs in responses (e.g., create_contact should return contact_id for downstream use); (5) Identifier parameter overloading (accepts 'id', 'email', or 'phone' but description doesn't clearly guide LLM on format, 'id:123' vs 'email:user@example.com' notation). Naming is strong (verb_noun, clear semantics), and all tools are single-responsibility. Schema structure is present but incomplete, parameters have types but lack numeric ranges, enums for status fields, and detailed constraint documentation.
Add tags to a contact.
Assign or unassign a conversation to a user.
Add a comment to a contact for internal reference.
Create a new contact in the workspace.
Create a new custom field.
Create a contact if they do not exist, or update the existing contact. Uses the contact identifier to match.
Create a workspace tag (used to tag contacts or conversations).
Output schemas are not documented in tool definitions. LLMs cannot plan downstream tool calls or extract required chaining IDs (e.g., contact_id after create_contact) without knowing response structure.
Identifier parameter accepts multiple formats (id:123, email:user@example.com, phone:+1234567890) but description does not clearly guide LLM on which format to use when. This invites format confusion and failed calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 68 | - | v1 |
Delete a contact from the workspace.
Delete a workspace tag by name.
Retrieve information about a specific contact by their ID, email, or phone number.
Get a custom field by its ID.
Retrieve a message by its ID.
Get a workspace user by their ID.
Get all messaging channels connected in the workspace.
List closing note categories/options used when closing conversations.
List contacts with optional filters and search.
Get a list of all custom fields in the workspace.
List messages for a contact with optional pagination.
List WhatsApp (or channel) message templates for a channel.
Get a list of users in the workspace.
Remove tags from a contact.
Send a message to a contact through a specific channel.
Update an existing contact's information.
Open or close a conversation.
Update an existing workspace tag.
Numeric parameters (limit, cursorId, messageId, channelId, id) lack explicit range constraints in descriptions (e.g., 'limit: 1-100' is stated for list_contacts but not for other list tools, and not enforced consistently). Without ranges, LLMs pass unbounded values.
Status and enum-like parameters lack explicit enum definitions. E.g., update_conversation_status accepts 'open' or 'close' but this is not declared as an enum; templateLanguage accepts 'en', 'en_US' but no enum is specified. LLMs may hallucinate invalid values.
Error handling guidance is absent from tool descriptions. No indication of when/how to retry, what errors are recoverable, or what the LLM should do on failure. E.g., delete_contact and delete_tag provide no recovery guidance.
Custom field parameter in create_contact and related tools is described as 'An array of custom field objects, each with a name and value' but the structure of each object (required keys, types, constraints) is not documented. LLM must guess the shape.
No indication which tools are idempotent vs. destructive/stateful. Agents need to know which calls are safe to retry. create_contact vs. update_contact both modify state, but agent doesn't know retry safety.
Descriptions for some tools are vague or lack context on when to use them. E.g., 'Update an existing contact's information' doesn't explain WHEN to use this vs. create_or_update_contact, or what fields are required vs. optional.