Loading ToolBench
First-party CometChat MCP server. Read-only tools for searching CometChat documentation, fetching pages, and pulling implementation bundles.
CometChat MCP server demonstrates solid quality with clear naming conventions, structured schemas, and helpful descriptions. All 5 tools follow verb-noun naming patterns (search, fetch_page, list_bundles, get_bundle, list_resources) that clearly indicate intent. Schemas are present and properly typed with JSON Schema. However, descriptions are minimal (under 100 chars for most tools) and lack depth around use cases, dependencies, and return value guidance. Parameter descriptions are sparse, 'query string' and 'bundle identifier' provide minimal context for LLM reasoning. Output schemas are undocumented, forcing LLMs to infer response structure. Error handling guidance is absent. Security and composition patterns are well-implemented (all tools are read-only, single-responsibility design), but error responses, edge cases, and downstream tool chaining are not addressed.
Fetch the full content of a specific CometChat documentation page
Fetch a specific implementation bundle with code examples and templates
List available implementation bundles (code examples and templates)
List available documentation resources and implementation guides
Search the CometChat documentation using full-text search
Output schemas are completely undocumented. LLMs cannot predict response structure for any tool. For 'search', it's unclear if results are paginated, what fields are returned, or how to chain results into fetch_page. For 'list_bundles' and 'list_resources', the schema is entirely opaque.
Parameter descriptions are minimal. 'query' is described as 'Search query string' without explaining format, length limits, or what kinds of queries work best. 'version' has no guidance on valid format or default behavior. 'path' in fetch_page has no examples of valid paths or URL conventions.
Tool descriptions lack context on when to use each. 'search' and 'fetch_page' serve different purposes but descriptions do not explain the workflow: when to search first vs. when to fetch directly. No guidance on dependencies (e.g., 'Call search() first to find a page path, then fetch_page() to get full content').
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
No error handling guidance. What happens if 'search' returns no results? If 'fetch_page' path is invalid? If 'bundle_id' does not exist? Descriptions should include recovery hints like 'If no results, try a broader query' or 'If bundle not found, call list_bundles() to see available IDs'.
Result limits are not declared. 'search' accepts a 'limit' parameter but no description of max/min bounds or default. 'list_bundles' and 'list_resources' provide no pagination or limit parameters at all, risking context window exhaustion if datasets are large.
No tool annotations (readOnlyHint, idempotentHint). While all tools are read-only (safe for agent experimentation), explicit annotations would signal this to clients and enable optimization.