Loading ToolBench
An MCP server providing tools to interact with Google Chat spaces, messages, members, and reactions via the Google Chat API
This server has 13 tools with mixed quality. Naming is generally verb-led (get_, send_, update_, delete_, list_, search_, create_), which is correct. However, descriptions vary significantly in quality and usefulness. Several tools lack actionable parameter constraints. Schemas are present but incomplete, many parameters lack type information in the visible code, though FastMCP may infer types from Python annotations. Three utility tools (add, fetch_weather, get_ip_my_address) are out of domain and dilute focus. The 11 Google Chat tools are well-structured overall, but descriptions could be more concise and parameter validation could be more explicit. Output schemas are not documented. Error handling is implicit (no recovery guidance visible). Critical issue: tool descriptions conflate implementation details with LLM-facing instructions (e.g., 'Make sure you have credentials.json downloaded' is a setup concern, not a tool behavior).
Add two numbers
Add an emoji reaction to a message in a Google Chat space.
Delete a message that this app sent. This permanently removes the message from the space for everyone, so double-check space_name and message_id before calling.
Fetch current weather for a city
List all Google Chat spaces the bot has access to. This tool requires OAuth authentication. On first run, it will open a browser window for you to log in with your Google account. Make sure you have credentials.json downloaded from Google Cloud Console in the current directory.
Get IP address from outian.net
Three tools (add, fetch_weather, get_ip_my_address) are completely out of domain and dilute the focus of a Google Chat server. They should be removed or moved to a separate utilities server.
No tool has a documented output schema. LLMs cannot plan downstream calls or extract fields without knowing what fields the response contains. Critical example: send_message returns a message object, but what fields does it have? (id? createTime? creatorEmail? thread details?)
Descriptions conflate user-facing behavior with setup/implementation details. E.g., 'This tool requires OAuth authentication. On first run, it will open a browser window for you to log in... Make sure you have credentials.json downloaded from Google Cloud Console in the current directory.' is setup guidance, not tool behavior. Separate setup instructions from LLM-facing descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Get a single message's full details from a Google Chat space.
List the members of a specific Google Chat space.
List messages from a specific Google Chat space with optional time filtering. This tool requires OAuth authentication. The space_name should be in the format 'spaces/your_space_id'. Dates should be in YYYY-MM-DD format (e.g., '2024-03-22'). When only start_date is provided, it will query messages for that entire day. When both dates are provided, it will query messages from start_date 00:00:00Z to end_date 23:59:59Z.
List the emoji reactions on a message in a Google Chat space.
Search messages in a Google Chat space for a keyword/substring match. The Chat API doesn't support full-text search server-side, so this fetches messages (optionally time-bounded, same date rules as get_space_messages) and filters them for a case-insensitive substring match on the message text.
Send a text message to a specific Google Chat space, optionally as a reply in a thread. This tool requires OAuth authentication with the chat.messages scope. The space_name should be in the format 'spaces/your_space_id'. This will post a visible message to the space, so double-check the space_name, thread_id, and text before calling. To reply within an existing thread, pass thread_id. A Google Chat message/thread URL looks like 'https://chat.google.com/room/{spaceId}/{threadId}/{messageId}' - space_name is 'spaces/{spaceId}' and thread_id is the {threadId} segment. If thread_id is omitted, a new thread is started.
Update the text of an existing message that this app sent. This will visibly edit the message for everyone in the space, so double-check space_name, message_id, and the new text before calling.
Parameter descriptions are verbose and sometimes include implementation details (e.g., 'Must start with client-, up to 63 chars, lowercase letters/numbers/hyphens only, unique within the space' for message_id in send_message). Constraints should be in schema validation, not description text. LLMs cannot parse character limits from prose.
No tools provide pagination info. get_space_messages and search_messages may return large result sets, but there is no mention of result limits, pagination tokens, or offset/limit parameters. LLMs cannot safely iterate large datasets.
Error handling is not visible or documented. No tool description explains what happens if space_name is invalid, date format is wrong, permissions are insufficient, or API rate limits are hit. LLMs have no recovery path.
Destructive operations (delete_message, update_message) lack confirmation or dry-run patterns. An agent calling delete_message with wrong message_id permanently removes it with no undo.
Naming inconsistency: create_reaction vs 'Add an emoji reaction' in description. Use consistent terminology (create vs add) throughout.
Parameter descriptions lack actionable format constraints for identifiers. E.g., space_name is documented as 'spaces/your_space_id' but LLMs don't know if 'spaces/AAAA1234' is the only valid format or if 'AAAA1234' alone is acceptable. Provide regex or explicit enum.