Loading ToolBench
An MCP server that optimizes hourly bid pacing for Google Ads campaigns using algorithmic PPC bid management
This MCP server exhibits critical deficiencies across all dimensions of tool definition quality. The single tool `execute_skill_action` has a reasonable name and basic schema, but lacks the rigor expected for production. The tool description is extremely terse (52 characters), providing minimal context for LLM selection. Input parameters lack meaningful descriptions, they are merely field names without guidance on formats, ranges, or constraints. The source code reveals a stub implementation that prints a hardcoded JSON response and does not actually implement the MCP protocol; the server neither accepts input nor implements request/response handling. No output schema is documented. Error handling is absent. The implementation is non-functional as an MCP server.
Execute algorithmic PPC bid pacing optimization
Tool description is extremely sparse (52 chars: 'Execute algorithmic PPC bid pacing optimization'). Lacks WHEN to use, what the tool returns, and prerequisites. Below the 10 - 1024 character guideline and well below the production baseline of ~194 chars. LLM cannot infer when to select this tool over alternatives.
Input parameter descriptions are missing or non-existent. 'campaign_target_roas' has only 'Target return on ad spend for the campaign', no guidance on valid ranges, constraints, or whether it is, e.g., 1.0 - 10.0 or 0.5 - 50.0. Same for 'current_hourly_spend_usd' and 'remaining_daily_budget_usd'. LLMs cannot validate input without explicit constraints.
Output schema is completely undocumented. The client.py stub returns a dict with fields like 'bid_decision_id', 'adjusted_cpc_bid_multiplier', 'projected_eod_budget_utilization_pct', etc., but there is no formal output schema definition. LLM does not know what fields to expect or their types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 30 | 2026-07-28+ | v2 |
No error handling or recovery guidance. The mcp_server.py stub prints a static response and does not actually process tool calls. There is no error classification, no actionable error messages, and no guidance for the LLM on what to do if the skill fails.
Input parameters lack type specifications and validation constraints. 'campaign_target_roas' and spend parameters are specified as 'number' but lack min/max bounds, step precision, or examples. LLM may pass invalid or nonsensical values (e.g., negative spend, ROAS of 0.001).
No documentation of parameter relationships or dependencies. It is unclear whether 'remaining_daily_budget_usd' must be >= 'current_hourly_spend_usd' * some multiplier, or what happens if it is not. Undocumented dependencies cause silent misuse.
Response fields like 'bid_adjustment_telemetry_url' appear to expose an internal telemetry endpoint. Tool responses should strip unnecessary internals and audit fields. User-facing agents do not need telemetry URLs, which dilute the signal and waste tokens.