Loading ToolBench
ChatGPT-Compatible Context7 MCP Bridge that implements ChatGPT's search/fetch specification while using Context7 internally
This MCP server has critical definition quality gaps across all four tools. Naming is reasonable but descriptions are generic/short and lack LLM-optimization. Input schemas are present but lack crucial detail: parameter descriptions are minimal, type constraints are missing, and output schemas are completely undocumented. The tool descriptions fail to explain WHEN to use each tool, what their return types are, or how they chain together. All tools are READ_ONLY but this critical information is missing from descriptions. The server functions as a wrapper around Context7, but the tool interface does not expose this relationship clearly to an LLM. Error handling is absent, no guidance on what to do when a call fails. The architecture subprocess-calls another MCP server, which is unusual and not clearly documented in tool descriptions.
Implement ChatGPT's fetch specification. Fetches full documentation for a specific library from search results cache.
Call Context7's get-library-docs tool to retrieve documentation for a specific library
Call Context7's resolve-library-id tool to resolve library names to Context7-compatible library IDs
Implement ChatGPT's search specification. Searches for Context7 libraries by query or direct library ID reference.
All tool descriptions are under 150 characters and lack WHEN/WHY guidance. 'Implement ChatGPT's search specification...' does not tell an LLM when to call search vs fetch vs resolve-library-id. Descriptions must explain the intent and distinguishing factors.
No parameter descriptions are present in the visible schema. The 'query' parameter in search has a description, but 'id' in fetch, 'libraryName' in resolve-library-id, and 'context7CompatibleLibraryID'/'topic'/'tokens' in get-library-docs lack ANY explanation of expected format, constraints, or purpose. LLMs cannot infer parameter semantics from names alone.
No output schemas are documented. LLMs cannot plan downstream calls or extract correct fields if they do not know what search() returns, what structure fetch() provides, or what fields resolve-library-id() yields. All four tools must document their return types and key fields.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 39 | <=2025-11-25 | v2 |
No error handling guidance in descriptions. When a search fails, fetch cannot find an ID, or Context7 is unreachable, there is no indication of what the LLM should do next. Descriptions must include recovery hints like 'Try search_users() if library is not found' or explain that the error is transient.
Parameter naming is inconsistent and uses system IDs instead of human-readable identifiers. 'context7CompatibleLibraryID' is verbose and opaque. The 'id' parameter in fetch is ambiguous, does it refer to a result object ID, a library ID, or something else? Tool descriptions should clarify and accept both IDs and friendly names.
The 'tokens' parameter in get-library-docs has no min/max constraints documented. An LLM could pass 0, 1000000, or a negative number and cause downstream failures or timeouts. Numeric parameters must include range constraints in the description.
Tool descriptions do not explain the relationship between tools or suggest composition. An LLM does not know whether to call search() then fetch(), or resolve-library-id() then get-library-docs(). Descriptions should include dependency hints and example call sequences.