Bug: "Request contains an invalid argument" when using with Gemini CLI

[aleks-mariusz]

Describe the bug
When using ToolsForMCPServer (v39) as an MCP Server for the Gemini CLI, every prompt sent to the Gemini API fails with a 400 - Request contains an invalid argument error. This happens for any prompt, even simple ones like "hi", effectively breaking the CLI's core functionality.

This may be the exact same issue as a previously reported bug in the gemini-cli repository: Issue #5030: API Error: Request contains an invalid argument.

The root cause in that issue was identified as recursive or overly deep schema definitions in the toolset sent to the Gemini API.

After analyzing the full schema of all 149 tools provided by the MCP server, the possible cause of these errors may be the following:

The tool classroom_courses_courseWork_rubrics_create provides a malformed JSON schema for its parameters.

The items object within the criteria property is defined as "type": "object" but is missing the required properties field.

Here is a snippet from this tool's schema:

"items": {
  "title": "Level",
  "description": "A level of performance within a criterion...",
  "type": "object"
}

This invalid schema is causing the Gemini API to reject the entire list of tools, which explains why every prompt fails.

To Reproduce

1. Create a Google App Script using ToolsForMCPServer version 39 and MCPApp - i used the instructions here
2. Deploy the script as a Web App.
3. Configure the Gemini CLI settings.json to use this Web App as an MCP server (also as per the above page).
4. Start the Gemini CLI (gemini).
5. Type any prompt, such as hi.

Expected behavior
A chat response should be returned from the model.

Actual behavior
An API error is returned immediately:

[API Error: [{
    "error": {
      "code": 400,
      "message": "Request contains an invalid argument.",
      "status": "INVALID_ARGUMENT"
    }
  }
]]

Additional context

• The /mcp command works correctly and lists all 149 tools from the server.
• The issue is present in version 39 of the ToolsForMCPServer library.
• The symptoms strongly suggest that the Gemini API is rejecting the entire /generateContent request because of an invalid tool definition, as described in the related gemini-cli issue #5030.

[tanaikech]

Thank you for your report. I confirmed the same issue. The reason for the issue was as follows.

get_charts_on_google_sheets: {
  description: "Use this to get all charts in a Google Spreadsheet. The response value includes the chart ID and the chart title of each sheet.",
  parameters: {
    type: "object",
    properties: {
      type: "object", // <--- This is the reason for the issue.
      spreadsheetId: { type: "string", description: "Spreadsheet ID of Google Sheets." }
    },
    required: ["spreadsheetId"]
  }
},

I modified the issue and updated it as v1.0.38. I could confirm that the update ToolsForMCPServer worked fine.

[aleks-mariusz]

Thank you for the quick response and for pushing an update.

I have updated to v40 and can confirm from my logs that I am receiving the new schema for get_charts_on_google_sheets.

Unfortunately, this did not solve the problem, and the Gemini CLI is still quite broken while using your code, with the same 400 - Request contains an invalid argument error.

I believe there has been a misunderstanding of the bug. The fix in commit ebf2219 corrected a different type of schema error than the one I reported.

• The bug you fixed (impressively quickly) was an invalid "type": "object" declaration inside a properties block in get_charts_on_google_sheets.
• I believe the bug still causing the malfunction is a missing properties block inside an items object that is declared with "type": "object". Update: nevermind, see updated below as i discovered the actual cause of my continued errors

This second bug seems to still exist, and i now realize is not isolated to a single tool either. After a more complete analysis, I can confirm that at least 10 tools have this specific error and are breaking the API validation.

Here is the complete list of tools with the invalid schema:

1. classroom_courses_announcements_create
2. classroom_courses_announcements_patch
3. classroom_courses_courseWork_create
4. classroom_courses_courseWork_patch
5. classroom_courses_courseWork_rubrics_create
6. classroom_courses_courseWork_rubrics_patch
7. classroom_courses_courseWork_studentSubmissions_patch
8. classroom_courses_courseWorkMaterials_create
9. classroom_courses_courseWorkMaterials_patch
10. classroom_courses_create

For each of these tools, the schema contains an items field that is defined as "type": "object" but is missing the required properties block, making it invalid.

Could you please have another look, let me know if my analysis is valid (i had AI-help of course :-) and if suitable, please re-open this issue and apply the necessary fix to all ten of these tool schemas? Thank you.

[aleks-mariusz]

Actually on second thought, this might have been something not set up correctly at my end it now seems - as having played around with this a bit more (via the google aistudio via this chrome extension) i now got this working, with no further changes needed in your code, but i needed to do the additional steps. This allowed me to also get it working in Gemini CLI as well!

Here is a summary of the key steps I had to take to get everything connected and working in both google-aistudio as well as gemini-cli:

1. Linking the new Apps Script (original idea from here) to a Standard Cloud Project:

• Problem: The Apps Script project (personal-google-mcp) by default runs in a hidden, default Google Cloud project. I couldn't find that project in the google cloud console to enable the necessary Google Drive API since it was in that default hidden project (this was advised per Gemini).
• Solution: I needed to click on the gear icon (while editing the script) to link the Apps Script project to one of my other standard, visible Google Cloud projects (which for me was the "Gemini API" project in my case). This was a critical step, as I believe is what made the project's settings manageable in the google cloud console.

2. Configuring the OAuth Consent Screen

• Problem: Before Google would allow the project linking, it required an "OAuth Consent Screen" to be configured. This screen tells users what an app wants to do with their data.
• Solution: I went into the Google Cloud Console for the selected project, went to the navigation menu (☰) in the top-left, then API & Services, then OAth section and completed the basic setup for the consent screen, designating it as "External" and providing the an app name and contact email (my own).

3. Authorizing the app script (an "Unverified" App) for myself as a Test User

• Problem: Because the script-app isn't publicly verified by Google (which is normal for personal projects), it's considered in "testing mode," and Google blocks access by default—even for myself, the developer.
• Solution: In the same OAuth section as above, under "Audience", I added my own email address to the "Test Users" list on the OAuth consent screen. This officially gave me permission to authorize and use my own app.

4. Re-Authorizing the Script with the New Permissions

• Problem: Although i had previously correctly set the deployment access to "Anyone," the script's permissions were still tied to the old, unlinked-project where it didn't have access to the Google Drive API. Simply linking the project in the settings doesn't automatically grant the running deployment new powers.
• Solution: I had to go and create another "New deployment," Apps Script detected that the underlying project now required a new permission (the Google Drive API scope). This is what triggered the "Authorize access" button to appear for the first time. By clicking it, I went through the OAuth flow this time, because I had already added yourself as a "Test User," the authorization was successful.

After i completed those four key steps, the connection was successfully established, and the tools were finally able to communicate with your Google Drive. It's a bit of a maze, but it's a one-time setup. The mcp-server is now fully configured for any future requests and hopefully the above steps may be helpful for others.

[tanaikech]

Thank you for your additional information. It will also be useful for other users.