Loading ToolBench
MCP server for Google Forms API
The server implements 3 tools for Google Forms with mixed quality. Tool naming follows verb_noun conventions (get_form, create_form, batch_update_form) which is correct. However, descriptions are present but lack actionable context for LLM selection. Parameter descriptions exist but are inconsistent in clarity. Schema definitions use Zod and are mostly complete for simpler tools but the batch_update_form has deeply nested oneOf structures that may confuse LLM interpretation. Error handling is minimal, no recovery guidance or categorization. The batch_update_form tool is particularly complex with a nested array of operations containing conditional logic that is not clearly documented in human-readable form.
Execute multiple update operations on Google Forms in a single batch. You can add, update, delete, and move items all at once. Supported operations: create_item, update_item, delete_item, move_item, update_form_info, update_form_settings [Note]: - If you want to provide created form url, use the url ending with "/viewform" instead of "/edit". - If you want to create a quiz form, first use the "update_form_settings" operation to set the form to quiz mode, and then use the "create_item" operation to add quiz items. You cannot set the form to quiz mode and create quiz items in the same request.
Creates a new Google Form. You can only specify the title.
Retrieve the structure of a Google Form. Use this as preparation for editing.
batch_update_form has a complex nested oneOf schema with 6 operation types. The schema is difficult to parse from JSON alone and lacks narrative documentation of how operations sequence. LLMs struggle with deeply nested conditional logic.
batch_update_form description contains a multi-line note about quiz mode workflow ('first use update_form_settings... then use create_item') but this dependency is not reflected in parameter descriptions or error handling. LLMs may violate this constraint.
No error handling guidance. Tools return errors but do not categorize as retryable vs user-fixable vs fatal. No recovery hints (e.g., 'If authentication fails, check GOOGLE_APPLICATION_CREDENTIALS').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
get_form and create_form descriptions are under 100 characters and lack context for when to use them vs alternatives. 'Retrieve the structure' and 'Creates a new Google Form' are functional but don't help LLMs understand the workflow.
batch_update_form schema has optional fields throughout (item_type, description, question_type, etc.) but no guidance on which are required for which operation types. LLMs may pass incomplete requests.
Parameter 'form_url' in get_form and batch_update_form accepts only Google Forms URLs, but the description does not validate format or provide guidance if URL is malformed. No regex pattern constraint visible.
create_form and batch_update_form are WRITE operations but tool descriptions do not explicitly state 'This modifies form state' or 'This creates a new resource.' LLMs need to know which calls are idempotent.
No documented output schema visible in tool definitions. Code shows tools return TextContent[] but does not document what fields are in the response or how to chain calls (e.g., what ID is returned by create_form for use in batch_update_form).