mcp-server-google-forms

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.0
Disambiguation5/5
Each tool targets a distinct resource/action: questions (add/update/delete/move), form metadata (create/get/update info, build), settings (publish, quiz), responses (list), and auth (status). No two tools serve the same purpose, and descriptions clarify any minor overlaps.
Naming Consistency4/5
Almost all tools follow a clear verb_noun pattern (e.g., create_form, list_responses, delete_question). The only exception is auth_status, which is a noun phrase, but its purpose is unambiguous and the overall convention is consistent.
Tool Count5/5
15 tools is within the well-scoped range for a Google Forms server, covering the full lifecycle (create, read, update, delete questions, manage form settings, list responses). build_form is a convenience wrapper but earns its place.
Completeness4/5
The tool set covers core CRUD operations, quiz configuration, and response retrieval. Minor gaps include no direct way to delete a form or list all forms, but these are often handled outside the Forms API and are not critical for typical workflows.
Average 4.1/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 50 commits in the last 12 weeks
- Last stable release on July 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention the tool can turn quiz mode on or off (implying reversibility) and that quiz mode includes grades ('com notas'), but it omits permission requirements, effects on existing responses or grading, and any validation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and key qualifier ('with grades'). Every word contributes to understanding, with no filler or redundant repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean setter with two fully described parameters, the description plus schema is largely complete. A slight deduction is made because there is no output schema or mention of the return value, and no explicit usage guidance relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both formId and isQuiz have descriptive schema text. The description does not add new parameter details, but the schema already fully explains the inputs, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Liga ou desliga o modo quiz (com notas) de um formulário' (turns on/off quiz mode with grades for a form). It names the resource (form) and the mode being toggled, distinguishing it from sibling tools like set_publish or update_form_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to enable or disable quiz mode on a form, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. Sibling tool names (e.g., set_publish) suggest the distinction, but the description itself offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It discloses the quiz mode requirement for points and the positional behavior via 'index'. However, it does not mention side effects like index shifting of existing questions, permissions, or error behavior, which are relevant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the main action and then provide necessary context (types and quiz mode caveat). Every sentence serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 17 parameters and no output schema, the description is relatively short but leverages rich per-parameter schema descriptions. It provides critical context about quiz mode and positioning, which complements the schema. It could mention return values or prerequisites like form existence, but the schema covers parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds the quiz mode prerequisite for points, but this is already noted in the schema ('exige modo quiz ativo'). Thus, the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Acrescenta uma pergunta a um formulário' (adds a question to a form). It further clarifies positioning ('no final, ou na posição indicada por index') and enumerates question types, effectively distinguishing this from siblings like update_question, delete_question, and move_question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: adding a question at the end or at a specific index, and it gives a specific prerequisite ('use set_quiz antes') for using points. However, it does not explicitly state when not to use this tool or mention alternative tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful behavioral context: the section break creates a new page and respondents advance via a 'Next' button, and positions count all items. However, it does not mention return values, error handling, or mutation specifics beyond 'insere', leaving some gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause adds value. It includes a behavioral note and a practical tip, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the main functionality, the indexing rule, and a verification tip. It does not describe the return value or error scenarios, but the simplicity of an insert operation and the presence of get_form as a check make this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats the index semantics ('As posições contam todos os itens') but this is already in the schema property description. It does not add new parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Insere uma quebra de seção (nova página) no formulário' (inserts a section break/new page). It distinguishes from sibling tools like add_question and add_text_item by specifying 'section break' (quebra de seção) and explains respondent behavior with the 'Próxima' button.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (to add a section break/page). It also provides a workflow hint: 'confira com get_form' (check with get_form) to verify positions. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the insert is static, has no answer field, and that indices count all items — valuable context. However, it doesn't mention side effects, permission requirements, or the response format for this mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb, and contains zero filler. Every sentence earns its place by adding the core purpose and a key behavioral nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple insertion tool with a well-documented schema, the description provides adequate operational context, including a verification hint. It would benefit from noting return value or error behavior, but is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description's note about positions counting all items is already present in the schema's index description, so it adds no additional semantic value beyond what is structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Insere' (inserts) and clearly identifies the resource as a 'bloco de texto estático' (static text block), distinguishing it from siblings via 'sem campo de resposta' (without an answer field). It clearly states what the tool does and how it differs from question/section tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that the block goes 'entre as perguntas' (between questions) and that positions count all items, advising to check with get_form. This gives clear placement and verification context, though it doesn't explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the default publication behavior, the draft option, and the fact that the response reports the actual publication state. This adds valuable insight beyond the basic creation action, though it does not cover permissions or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. It front-loads the primary action and efficiently adds key behavioral details, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values (ID, edit link, response link) and the publication state. The tool is simple (3 params, no nested objects), and the description covers the essential aspects without leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with clear descriptions (100% coverage). The description adds only slight value by restating the default publication behavior for the unpublished parameter, but it is largely redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action: 'Cria um novo Google Form vazio' (creates a new empty Google Form) and specifies the returned resources (ID, edit link, response link). This distinguishes it from sibling tools that add or modify content within a form, such as add_question or update_form_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit usage context by explaining the unpublished parameter and the default published state, but it does not explicitly compare with alternatives like build_form or say when NOT to use this tool. It lacks direct references to sibling tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral constraint: the Drive documentTitle cannot be changed after creation, which is not obvious from the schema. It also clarifies that the 'title' refers to the respondent-facing header, not the file name. However, it doesn't mention side effects, permissions, or error behavior, so it's not fully transparent, but it adds meaningful context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written in two sentences. The first sentence states the action and scope; the second adds a relevant constraint. No filler or repetition of the schema. It is front-loaded with the primary purpose and earn every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata update tool with no output schema, the description is largely complete. It covers the main functionality and a critical limitation (documentTitle immutability). It does not mention prerequisites like form existence or permissions, but given the low complexity and the schema providing required fields, it is nearly complete. A slightly higher score would require more operational detail, but this is sufficient for straightforward use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with basic descriptions ('Novo título', 'Nova descrição'), so the baseline is 3. The description adds value by clarifying that 'title' is distinct from the Drive file name (documentTitle), preventing a common confusion. This semantic clarification about the title parameter justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to change the title and/or description of an existing form. It specifies the resource (form) and the exact fields affected, and distinguishes it from siblings like update_question or create_form by focusing on the form's top-level metadata. The parenthetical about what appears at the top for respondents removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. While it's implicitly clear that this is for editing title/description, there is no mention of prerequisites (e.g., needing to retrieve the form first), when partial updates are allowed, or when to prefer other tools like update_question or set_publish. The description lacks any 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses a key side effect (not deleting/recreating the question, thus preserving responses) and points to get_form for position lookup. However, it does not state whether only provided fields are updated, what failure modes exist, or what permissions are required, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one main sentence listing scope and side effects, plus a short actionable pointer to get_form. Every phrase adds value, including the 'sem apagar e recriar' preservation guarantee.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a fully described 7-parameter schema and the get_form reference, the description gives an agent enough to correctly select and invoke the tool. The main gap is the lack of partial-update semantics or return/error behavior, but these are partially inferable from the schema and less critical given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive comments, so the baseline is 3. The description maps high-level concepts (enunciado, obrigatoriedade, alternativas, pontos, gabarito) to fields but adds no semantic detail beyond the schema. The index guidance duplicates the schema's existing pointer to get_form.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Altera uma pergunta existente na posição indicada', a specific verb+object+scope. It enumerates updatable attributes (enunciado, obrigatoriedade, alternativas, pontos, gabarito) and differentiates from destructive alternatives by noting it preserves the link to received responses. Sibling tools like delete_question, move_question, and add_question make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent to verify the target position with get_form ('Confira a posição com get_form') and gives a strong reason to use this tool instead of delete+recreate: it preserves the link to already received answers. It doesn't explicitly contrast with alternatives like move_question or update_form_info, but the guidance is practical and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys non-mutating verification behavior through verbs like 'Confere' and 'auditar', implying a read-only check. However, it does not disclose the return format, potential error conditions, or explicitly guarantee that the form is not modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the verb and resource. The first sentence explains what it does, the second provides usage context. Every word earns its place without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple verification tool with 2 parameters, the description covers purpose and usage context well. It lacks return-value specification and explicit non-mutation disclosure, but given the simplicity and full schema coverage, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both formId and expected have descriptions), so baseline is 3. The tool description adds context about comparing against expected answers and points, but it doesn't significantly enhance parameter understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Confere' (checks) with the resource 'gabarito de um quiz', clearly stating the operation. It further explains it verifies correct answers and points per position, distinguishing it from sibling CRUD tools by emphasizing audit/verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Útil para auditar um quiz recém-montado antes de divulgar' (useful for auditing a recently assembled quiz before publishing). While it doesn't explicitly exclude alternatives or mention when not to use, the context is clear and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently states 'sem alterar nada' (without changing anything), marking it as read-only, and enumerates the checks performed. However, it does not disclose potential network calls, rate limits, or the exact output format, leaving some ambiguity about what the agent will receive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence defines scope and non-destructive behavior; the second gives a concrete use case, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple diagnostic tool with no parameters and no output schema, the description explains purpose, non-mutation, and when to use it. The lack of return format details is a minor gap, but the stated checks and usage guidance are sufficient for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is complete and the description adds context about the checks performed (file existence, completeness, token acceptance), going beyond the empty schema. Per the rubric, 0 params warrants a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Verifica a configuração de acesso ao Google' (checks Google access configuration) and lists three specific checks: credential file existence, completeness, and refresh token acceptance. It clearly distinguishes itself from sibling tools, which all handle form/question operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit usage trigger: 'Use quando alguma ferramenta falhar por autenticação' (use when any tool fails due to authentication). It lacks explicit alternatives or exclusions, but the stated scenario is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavior: positions count all items (not just questions), starting at 0, and that the tool refuses to delete non-question items. This goes beyond the basic action but doesn't mention irreversibility or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and efficient in conveying constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core action, indexing caveat, and safety restriction, which is adequate for a simple two-parameter deletion tool. It lacks explicit error behavior for invalid indices but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both formId and index; the tool description's indexing note is partially redundant with the schema's index description. It adds no new parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a question at a specified position, using a specific verb ('Remover') and resource ('pergunta'). It also differentiates from siblings by specifying that only questions are affected, not other form items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises checking with get_form before deletion to confirm positions, and explicitly states the tool refuses to delete non-question items, giving a clear when-not. However, it doesn't name specific alternative tools for deleting other item types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses a key behavioral trait: raw=true includes the complete API JSON and produces much larger output ('saída bem maior; só quando o resumo não bastar'), adding context beyond the schema. It also clarifies the output structure (general data + item list), which is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary purpose, and includes necessary details about raw and sibling-tool usage without any wasted words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 2 parameters and no output schema, the description covers the essential parts: what it returns (structure, items, positions) and the raw option. It also connects to sibling tools. It could explicitly state it's a read-only operation, but the verb 'Mostra' implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context linking the output positions to sibling tools, but it doesn't add significant meaning about the parameters themselves beyond what the schema already states. The raw parameter is already well described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Mostra a estrutura de um formulário: dados gerais e a lista de itens com as posições' (shows the form structure: general data and item list with positions). It uses a specific verb ('Mostra' / shows) and a resource ('formulário'), and differentiates from siblings by mentioning its output is used in add_question, delete_question, and move_question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by saying the positions are to be used in sibling mutation tools (add_question, delete_question, move_question), implying when to use this tool. It also explains the optional raw=true for full JSON, but it doesn't explicitly exclude alternative tools like list_responses for response data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination behavior (default 50, pageToken forwarding) and the response format transformation. However, it doesn't explicitly state the operation is non-destructive or mention auth/error behavior, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and add pagination details without wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains pagination and the nature of the returned data (with question text). It falls short of describing the full response structure or error handling, but is sufficient for a read-oriented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description reiterates the default page size (already in schema) and pageToken usage. It adds no new parameter-level information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists form responses and specifies a key transformation (question text replaces internal code). This distinguishes it from sibling tools, which focus on form editing/creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides contextual usage: lists responses with pagination. Doesn't explicitly name alternatives or when not to use, but the read-only nature contrasts with sibling editing tools. Implied usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds important details not in the schema: positions count ALL items and are 0-based. However, it does not explain side effects like shifting of other items or the nature of the response, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a parenthetical caveat, front-loading the action and giving essential positional context. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter reorder tool with no output schema, the description covers the core action, position semantics, and a practical prerequisite. It could mention impact on other items or return behavior, but given the tool's simplicity and the guidance to use get_form, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter descriptions, so the baseline is 3. The description adds meaning by clarifying that 'from' and 'to' refer to positions counting all items from 0, which is not fully specified in the schema descriptions. This extra context enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves an item from one position to another, with a specific verb and resource. It distinguishes from siblings like delete_question and update_question by focusing on reordering. The title 'Reordenar pergunta' reinforces this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite by advising to check with get_form before moving, which is valuable context for using the tool correctly. It does not explicitly exclude alternatives or mention when not to use, but since no other sibling tool does reordering, the usage context is sufficiently implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the behavior (publish/unpublish) and adds that unpublished forms do not accept responses, explaining the practical consequence. It does not cover potential side effects or permissions, but for a simple toggle this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core functionality, the second provides essential context about initial state. No unnecessary words or repetition, perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and a clear toggle behavior, the description is complete. It explains the starting state, the effect on response acceptance, and the expected use case. There is no output schema, and none is needed for this state-change operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with clear descriptions: formId is the form ID, published explains true makes it visible and accepting responses, false unpublishes. The description adds the context that forms start unpublished, which reinforces the meaning of the 'published' parameter but doesn't introduce new syntax or format details beyond the schema's high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action: 'Publica ou despublica um formulário' (publishes or unpublishes a form), using a specific verb and resource. It distinguishes itself from sibling tools that deal with questions, sections, or responses by explicitly mentioning the publish/unpublish toggle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context: forms created via API start unpublished and do not accept responses until published, implying this tool should be used after form creation to enable responses. It gives a clear 'when to use' signal, though it does not explicitly exclude alternatives or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and it discloses a critical behavioral trait: by default, the form is already published, and users must set unpublished=true to create a draft. This is a significant side effect beyond parameter definitions. It does not cover permissions, rate limits, or error cases, but the key publish-state behavior is well highlighted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states purpose, the second gives a direct usage recommendation, and the third highlights a critical default behavior. Every sentence earns its place with no redundancy or filler, front-loading the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested questions) and lack of output schema, the description covers the main operational aspects: what it creates, order preservation, and publication default. It does not mention the response format or failure modes, but the schema covers parameter details, making this reasonably complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing solid parameter docs. The description adds value by clarifying the 'unpublished' parameter's impact (default published vs draft) and stressing that questions appear 'in the given order', which maps to the questions array. This meaningfully enhances the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an entire form in one operation, listing the included components (title, description, quiz mode, all questions in order). It explicitly distinguishes from siblings by advising to prefer this over chaining create_form and multiple add_question calls, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance by recommending this tool over chaining create_form + add_question, which directly addresses when to use it. It also mentions the unpublished parameter for draft creation, offering context on how to control publication. However, it does not mention when not to use it (e.g., for incremental updates or large forms beyond limits), so it misses some exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-google-forms MCP server](https://glama.ai/mcp/servers/claude-book/mcp-server-google-forms/badges/card.svg)](https://glama.ai/mcp/servers/claude-book/mcp-server-google-forms)

Score Badge

Copy to your README.md:

[![mcp-server-google-forms MCP server](https://glama.ai/mcp/servers/claude-book/mcp-server-google-forms/badges/score.svg)](https://glama.ai/mcp/servers/claude-book/mcp-server-google-forms)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/claude-book/mcp-server-google-forms'

If you have feedback or need assistance with the MCP directory API, please join our Discord server