Loading ToolBench
A Model Context Protocol server that provides AI agents access to the Codex documentation wiki with support for search, read, create, update, delete operations on pages and folders
Codex MCP Server demonstrates good baseline quality with 14 well-named tools covering wiki operations (CRUD for pages/folders, search, history/versioning). All tools have descriptions and basic parameter schemas. However, gaps exist: parameter descriptions lack format constraints and dependency documentation, output schemas are not explicitly defined, error handling lacks recovery guidance, and destructive operations lack confirmation mechanisms. The server follows verb_noun naming consistently (search_pages, create_page, delete_folder) and parameters are logically structured. Most tools fall into 'good' range (70-79) rather than exceptional (80+), pulling the average toward B territory.
Create a new folder in the Codex wiki
Create a new page in the Codex wiki
Delete a folder from the Codex wiki
Delete a page from the Codex wiki
Get the Git-backed version history for a page in the Codex wiki
Get a specific historical version of a page from the Codex wiki
Get the complete folder tree structure of the Codex wiki
List all pages in the Codex wiki, optionally filtered by folder
Destructive operations (delete_page, delete_folder, restore_page_version) lack confirmation/dry-run mechanisms. No description states these are irreversible or how to verify before executing.
Output schemas are not explicitly documented in the provided code. LLMs cannot plan downstream tool chains (e.g., after search_pages returns results, what fields are available to filter on?). This forces extra discovery calls.
Parameter descriptions lack format constraints and validation rules. 'path' parameters do not specify valid format (e.g., 'folder/page.md', allowed characters, max length). 'query' for search_pages has no length/character constraints. LLMs will pass unbounded input.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 60 | 2025-03-26+ | v1 |
Read the content of a specific page from the Codex wiki
Rename a folder in the Codex wiki
Rename a page in the Codex wiki
Restore a page to a specific historical version in the Codex wiki
Search across all pages in the Codex wiki using full-text search
Update the content of an existing page in the Codex wiki
Error handling guidance is absent from descriptions. Tools do not state: 'If path not found, will return error; consider using search_pages first.' No recovery hints guide LLM retry logic.
Parameter relationships undocumented. For example, rename_page and rename_folder use (oldPath, newPath), but descriptions don't state whether newPath is absolute, relative, or must be in the same folder. Rename-across-folders semantics are unclear.
No description of what list_pages returns when folder is specified vs. omitted. Does 'folder' filter to that folder only, or is it a search root? Does it recurse into subfolders? LLM cannot reason about result scope.
Content parameters ('content' in create_page, update_page) have no stated length limits, encoding expectations, or constraints. LLMs may attempt to pass binary data or massive markdown blobs without guidance.
No pagination parameters (limit, offset, cursor) on list_pages or list_folders. If wiki has thousands of pages, response could exceed context window. No result count or next_cursor guidance.
search_pages has no limit parameter and no documented result cap. A broad query could return hundreds of pages, exhausting context window. Baseline production servers cap list results at 20-50.
Git commit hash (hash parameter in get_page_version, restore_page_version) is opaque to LLMs. No guidance on how to obtain valid hashes (get_page_history returns them?) or what happens if hash is invalid.