Loading ToolBench
MCP server that adds range-anchored (inline) comments to Google Docs — the one comment operation the Google Docs/Drive APIs cannot do — by driving a real logged-in Docs session with Playwright.
Two tools with complete schemas and strong descriptions. add_comment has excellent, detailed guidance (400+ chars) explaining when/why to use it and prerequisites. check_connection is clear and concise. Both tools have proper input schemas with typed parameters and descriptions. However, output schemas are not formally documented in the code, only described in prose. No tool annotations (readOnlyHint/destructiveHint). Error handling is present but generic. Naming is clear and verb-forward.
Add an inline comment anchored to a specific text fragment in a Google Doc (the comment is pinned to that exact phrase, like selecting text and commenting on it by hand). USE THIS WHEN the user wants to leave feedback, notes, questions, edits, or review comments on specific passages of a Google Doc — e.g. "review this doc and comment on the weak spots", "leave a comment on that sentence", "add editorial feedback inline". This is the ONLY way to place anchored comments: the Google Docs and Drive APIs cannot anchor a comment to a text range, so this drives a real logged-in Docs session in a browser. Do NOT use for list/reply/resolve/delete — those work over the Drive API. Requires a one-time `npx gdocs-comments-mcp login` by the human operator (you cannot log in for them). Omit find_text to add a general, unanchored comment on the document instead. Returns only { ok, anchored, occurrence_used, verified } — never document content.
Check whether the Google session behind this server is usable: launches/attaches the browser and probes docs.google.com. Returns { connected, mode }. Call this to diagnose failures; if connected=false, ask the operator to run `npx gdocs-comments-mcp login`.
Output schemas not formally documented. Tool descriptions mention return structure ({ ok, anchored, occurrence_used, verified }) in prose only; no JSON Schema definition visible in code.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). add_comment is destructive (WRITE risk) but not marked; check_connection is read-only but not annotated.
Error handling returns generic error codes (NOT_CONNECTED, SESSION_EXPIRED, etc.) but lacks recovery guidance in tool descriptions. LLM must infer next steps from server instructions rather than per-tool error context.
add_comment parameter 'occurrence' lacks minimum/maximum bounds in description. Schema declares minimum: 1 but no maximum, unbounded integers could cause unexpected behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
No batch variants. If an agent needs to add multiple comments, it must call add_comment sequentially, wasting tokens and latency. A batch_add_comments tool would improve efficiency.