Loading ToolBench
MCP server for Capsule CRM integration, written in Scala. Provides tools for searching and managing contacts in a Capsule CRM account.
Scala MCP Server exhibits significant quality gaps across naming, parameter descriptions, and schema documentation. While tool names follow verb_noun conventions (search_contacts, list_contact_custom_fields, describe_*), the parameter documentation is severely lacking. The 'filter' parameter in search_contacts has a description ('array of zero or more conditions') but provides no guidance on the Filter object structure, expected fields, operators, or constraints. The pagination parameter has better structure but lacks range constraints (e.g., 'page must be ≥1', 'perPage typically 1-100'). Critically, the filter parameter lacks any type information or schema structure visible in the code, only a generic object placeholder. Output schemas are completely undocumented; callers have no way to know what fields search_contacts returns, making downstream tool composition impossible. The describe_search_contacts and describe_contacts tools exist as workarounds for missing inline documentation, indicating the primary tools lack sufficient self-documenting schemas. Error handling is absent, no indication of what happens if filter conditions are invalid or if a request times out. The server provides no guidance on recovery, retries, or field validation.
Returns the available fields that can be requested for contacts in CRM account
Returns a detailed description of how to use the `search_contacts` tool.
List custom fields in CRM account (useful for looking up a custom field's ID to use in a `search_contacts` request)
Perform a search of contacts. Refer to `describe_search_contacts` for tool description and usage
Filter parameter in search_contacts lacks schema documentation. No visible type definition, required fields, operator constraints, or value types. Only a generic object placeholder shown. Callers cannot determine valid filter syntax without calling describe_search_contacts first.
Pagination parameters (page, perPage) lack range constraints and defaults are stated only in code comments, not in parameter descriptions. No indication of valid ranges (min/max page numbers, max results per page).
Output schemas for all tools are completely undocumented. search_contacts returns PartyResponse serialized to JSON, but callers cannot see what fields it contains, data types, or structure. Impossible to compose downstream tool calls or extract relevant data.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
Discovery tool pattern is anti-pattern: search_contacts references describe_search_contacts in its own description instead of being self-documenting. This requires LLM to make an extra call to understand the primary tool, wasting tokens and rounds.
No error handling guidance visible. No indication of what happens on invalid filter syntax, network timeouts, permission errors, or invalid pagination. No recovery hints for LLM.
Pagination in search_contacts and list_contact_custom_fields lacks result count or next_cursor. Without knowing total results or offset, LLM cannot paginate through large result sets effectively.
Field 'tag' in filter reference (describe_search_contacts) accepts 'Number, string' with no clarification on when to use each type. Creates ambiguity for LLM.