Loading ToolBench
MCP server for querying Opine deals, evaluations, and tickets
This server has 12 tools with clear naming conventions (verb_noun format: list_, get_, create_, update_). All tools have descriptions and input schemas. However, there are significant gaps in schema completeness, parameter descriptions, and output documentation that prevent a higher score. The schemas are present but inconsistently detailed, some parameters lack descriptions (e.g., 'description' field in update_ticket and create_ticket has no type specified, only a description about format). No output schemas are documented. Error handling is absent from the definitions. The server follows basic naming patterns well but falls short on LLM-optimization of descriptions and schema rigor expected for production tools.
Create a note on a deal in Opine. Requires notes:write scope.
Create a new ticket in Opine. Requires tickets:write scope.
Get a deal along with resolved sales process and stage metadata
Get a specific deal by ID
Get a specific deal by Salesforce ID (automatically converts 15-char to 18-char and prepends "eid:" prefix)
List deals from Opine CRM
Output schemas completely undocumented. No tool defines what fields are returned, their types, or whether pagination metadata is included. LLMs cannot plan downstream tool calls or extract required data without knowing the response structure.
The 'description' parameter in update_ticket (and create_ticket) lacks a type definition. The description says it accepts 'Slate node array, markdown string, or null' but the JSON schema shows only a description field with no 'type' property. This violates JSON Schema correctness and prevents LLMs from understanding valid input formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
List evaluations from Opine
List notes from Opine. Requires notes:read scope.
List sales process stages from Opine
List sales processes configured in Opine
List tickets/requests from Opine
Update an existing ticket in Opine. Requires tickets:write scope.
Pagination results lack documented total counts or next_cursor fields. Tools like list_deals, list_tickets, list_evaluations accept limit/offset but there is no documentation of whether the response includes a total count or how to know if more results exist. This prevents proper pagination implementation by LLMs.
No error handling documentation. Tools lack guidance on what errors can occur, whether they are retryable, or what the LLM should do next. A user calls get_deal with an invalid ID, the tool should return a clear error like 'Deal not found (ID: xyz). Try list_deals() to find valid IDs.' instead of a bare error code.
Parameter descriptions are generic or incomplete. Example: 'list_evaluations' has only 'List evaluations from Opine' as description, does not clarify what an evaluation is, when to call it, or how results differ from other list tools. Per pattern, descriptions should answer WHAT, WHEN, and WHY.
Pattern constraint declarations are weak. The 'pattern' field on ID parameters is '^.+$' (matches any non-empty string) which is not restrictive. If Opine IDs have a specific format (e.g., numeric, UUID, prefixed), the pattern should enforce it. Currently, any string passes, allowing invalid IDs to be sent to the API.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Write operations like update_ticket, create_deal_note, create_ticket lack explicit destructiveHint marking. This prevents agents from understanding mutation risk and planning accordingly.
Inconsistent parameter documentation detail. Some tools like update_ticket have detailed descriptions of enum values (BLOCKER|IMPORTANT|NICE_TO_HAVE), while others like list_evaluations and list_sales_processes have minimal parameter docs. This inconsistency makes it hard for LLMs to predict required format.