Loading ToolBench
Model Context Protocol server for Google Drive integration, deployable to Cloudflare Workers
This Google Drive MCP server has reasonably complete tool definitions with clear naming and mostly good descriptions. However, there are consistent gaps in schema completeness, output documentation, and error handling guidance. 11 of 12 tools have descriptions; all use action verbs. Most parameters are typed and described. The main weaknesses are: (1) output schemas are not documented anywhere in the visible code, LLMs cannot predict what fields to expect after calling tools like get_document or list_documents; (2) error handling provides no recovery guidance, errors are likely raw API responses rather than actionable messages; (3) parameter relationships (e.g., tabId availability depends on document structure) are under-documented; (4) no confirmation patterns for destructive operations (update_document, create_document, replace_section); (5) two tools (update_document, replace_section) show file paths in 'File' field pointing to beast-scripts/check-deployment.mjs, suggesting these may be inferred definitions rather than directly visible in the main tool registry.
Create a new Google Doc
Export a Google Doc in a specified format (markdown, text, PDF, or DOCX). Returns structured metadata and embedded resource with file content.
Read a section until the next heading of equal or higher level within its tab. Provide exactly one of headingId or headingText. Ambiguous matches and headings inside tables are rejected. Returns tab and revision metadata.
Get a Google Doc including all nested tabs and revisionId (when the caller has edit access). Use tab-local UTF-16 indices for updates.
List document headings with heading IDs, tab IDs, UTF-16 indices and revisionId; TITLE is treated as level 1. Filter by tabId to avoid ambiguity.
Output schemas not documented. No visible documentation of what fields tools return (e.g., get_document structure, list_documents pagination format, export_document embedded resource format). LLMs cannot plan downstream tool calls or extract specific fields without knowing the response structure.
No error recovery guidance. Error responses likely return raw API errors (e.g., 'not found', 'permission denied') without actionable next steps. LLMs need guidance: Is this retryable? Should the user be asked? Should a different tool be tried?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Get metadata about a Google Doc (without full content)
List Google Docs tabs, including nested children in preorder, with real tab IDs, hierarchy and revisionId. Legacy body-only responses have a null tabId.
Get plain text from one tab or all tab bodies in preorder, with revisionId when available. Export fallback is unavailable when tabId is specified.
List Google Docs in the user's Drive
Replace a section of a document (between two headings or from heading to end). Atomically deletes the old section and inserts new content. Supports rich formatting via Google Docs structured format or plain text.
Search for Google Docs by content or title
Update a Google Doc with batch requests (insertText, deleteContentRange, updateTextStyle, etc.). Requires revisionId for optimistic concurrency control.
Destructive operations lack confirmation pattern. update_document, create_document, and replace_section modify or create data without dry-run or confirmation step. Agents make mistakes, no safeguard against accidental overwrites.
Parameter interdependencies underdocumented. tabId availability and behavior depends on document structure (get_document_tabs lists real tab IDs vs legacy null tabId). Multi-tab parameter semantics (headingId vs headingText in get_content_under_heading, matchMode enum) need explicit mutual exclusivity and dependency rules in descriptions.
update_document and replace_section have unclear input schemas. The update_document 'requests' parameter is described as 'Array of update requests (Google Docs API batchUpdate format)', this is an opaque reference to external API docs. No inline schema or examples. LLMs cannot generate valid requests without seeing the format.
Tool definitions for update_document and replace_section appear to be sourced from beast-scripts/check-deployment.mjs rather than src/tools/index.ts, suggesting these may not be directly visible in the main tool registry. If so, their definitions are inferred and should be capped at 50 per scoring rules.
Pagination design incomplete. list_documents and search_documents accept pageSize and pageToken but do not document: (1) total count or hasMore flag in response; (2) what the first call's pageToken value should be; (3) whether pageToken is opaque or decodable. Without these, agents cannot reliably iterate through paginated results.
revisionId semantics under-specified. get_document returns revisionId 'when the caller has edit access'. update_document accepts optional requiredRevisionId for 'optimistic concurrency control'. No description of: (1) what happens if revisionId is stale; (2) whether requiredRevisionId is required or truly optional; (3) how to handle conflicts. LLMs cannot reason about concurrency without clear semantics.