Loading ToolBench
A Google Workspace assistant backend that integrates two MCP servers (Context MCP and Action MCP) to read user context and write outputs via Google Chat webhooks
This server exhibits significant definition quality gaps. Tool names lack consistent verb-noun structure (e.g., 'context_toolset', 'action_toolset', 'build_llm_agent' are vague about what they do). Descriptions exist but are often generic or assume domain knowledge (e.g., 'Build the Context MCP toolset' doesn't explain WHEN to call it or WHAT it returns). Input schemas are present but incomplete: many parameters lack type definitions or descriptions (e.g., 'store' in authorize is typed as 'object' with minimal guidance). Output schemas are entirely undocumented, no tool specifies what it returns. Error handling is absent; tools provide no recovery guidance. The server conflates infrastructure concerns (building toolsets, constructing agents) with user-facing operations, violating single-responsibility principle.
Build the Action MCP toolset. No user identifier is sent: the Action MCP authenticates as a single service account and writes only to the designated Shared Drive.
Decide whether user_email may invoke the workflow with command_id. Evaluates access rules from the database against the user's email and domain.
Whether user_email is allowed to call admin slash commands. Bootstrap admins are governed by BOOTSTRAP_ADMIN_EMAILS environment variable, not by the rules table.
Construct an LlmAgent with the app-standard model + description.
Build the Context MCP toolset bound to user_email. The email is sent as a header (not a tool argument) so that the LLM is structurally incapable of impersonating another user — even under prompt injection.
Route a CARD_CLICKED event to its handler by invoked action function. Registered functions (invite dialog, RFI/IQ form submits) dispatch directly; everything else falls back to the owner handler.
No output schemas documented. Tools return unspecified structures; LLMs cannot plan downstream calls or extract required fields. Violates pattern:tool and pattern:response-shaper.
Tool names lack action verbs or are infrastructure-focused rather than user-intent-focused. 'context_toolset', 'action_toolset', 'build_llm_agent' do not clearly signal what the LLM should do. Violates pattern:tool naming convention.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Entry point for Google Chat webhooks. Verifies the inbound JWT and forwards the payload to the chat event handler.
Apply the owner/due-date form and resume the meeting pipeline. This is the default CARD_CLICKED handler.
Post the tailoring form (if still pending) or the final dossier reply.
Post the agent's result, branching to each workflow's form/UI logic.
Seed IQ_COMPANY_NAME from the slash prompt before the pipeline runs. Returns None on success or a user-facing error string to post.
Run any per-workflow preparation before the agent runs. Returns a user-facing error string to post (and abort) on failure, or None when there's nothing to prepare or prep succeeded.
Register function_name → handler for CARD_CLICKED dispatch. Decorator for registering card event handlers.
Parameter descriptions are generic or missing. 'store' in authorize is typed 'object' with minimal guidance; 'background_tasks' in handle_event lacks explanation of what it does. LLMs cannot infer parameter meaning. Violates pattern:tool-description.
No error handling or recovery guidance. Tools provide no indication of failure modes, retryability, or next steps. Violates pattern:recovery-guide and pattern:error-classification.
Single-responsibility principle violated. Tools like 'prepare_slash_workflow' and 'post_slash_workflow_result' mix preparation, validation, and posting logic. Should decompose into separate tools (validate_workflow, post_result). Violates pattern:tool.