MCP server for Google Workspace integration including Docs, Sheets, Drive, Apps Script, Gmail, and Calendar APIs
Scoring was not performed
Only 2 of 6 tools are visible in provided source code. Tools listed in index.ts (registerGmailTools, registerCalendarTools) and the filter tools (setBasicFilter, clearBasicFilter) are declared but not implemented in the snippet. Per hard scoring rules, inferred-only tool definitions must be capped at 50.
All tools return unstructured markdown strings instead of structured JSON objects. This forces LLMs to parse freeform text, which is error-prone and wastes tokens. Example: createBoundScript returns 'Apps Script project created successfully!\n\n**Script ID:** ${scriptId}' instead of {scriptId, title, parentId}.
No enum constraints on any inputs. Parameters like 'type' in updateScriptContent (with values SERVER_JS, JSON) are properly constrained in Zod schema, but descriptions lack clarity on these constraints. Parameter descriptions should explicitly list valid values to help LLMs self-correct. Example: updateScriptContent files[].type description should say 'One of: SERVER_JS (for .gs files) or JSON (for manifest)'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 22 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Parameter descriptions lack dependency hints and format guidance. 'parentId' in createBoundScript has no guidance on format (is it a URL, UUID, or opaque string?). 'range' in setBasicFilter is an object with optional nested properties but lacks clear explanation of what each nested field does.
Error messages are generic. While code wraps errors in UserError (good), messages like 'Failed to create Apps Script project: ${error.message}' do not guide the LLM on recovery.
No output schema documentation. Tools return markdown; there is no formal schema describing what fields are present, their types, or what an LLM should expect. LLMs need to know what fields to expect so they can plan downstream tool calls.' None of the visible tools document their return structure.
Tool names use verb_noun convention (good: get_, create_, update_) but do not follow per-tool semantic clarity. Example: 'setBasicFilter' vs 'clearBasicFilter' are clear, but descriptions are weak and parameters lack context about what a 'basic filter' is (Sheets auto-filter feature?) and when to use it vs other filtering approaches.
getScriptProjects uses pageSize parameter with min=1, max=50, default=10, good constraint. However, other tools have no pagination or result limits. If getScriptContent returns a large script with hundreds of files, the entire response is dumped.