Loading ToolBench
Governed, read-only MCP server exposing Google Ad Manager inventory discovery to buyer agents
Well-structured tool definitions with clear naming (verb_noun pattern), comprehensive parameter descriptions, and explicit security/idempotency guidance. All 5 tools have descriptions (194 - 280 chars, within baseline 34 - 392 range). Parameters include type, description, and security context. However, output schemas are not documented in the source code provided, and tool annotations (readOnlyHint/destructiveHint/idempotentHint) are absent. Error handling guidance is minimal. Composition is sound: tools are single-responsibility and chain via token/family_id/intent_id references.
Register a firm buying intent at the family's current firm price. A soft, TTL'd commitment (not a GAM order or inventory hold). Price must match the advertised firm price; mismatch/stale price is rejected.
Discover product families available to the authenticated buyer, with firm pricing if entitled
Get coarse availability forecast for a product family in a given period (buckets, never exact impressions)
Withdraw one of your own active intents by id. Buyer-scoped: revoking anything that is not your own active intent returns the same generic INVALID_REQUEST (you cannot probe others' intents).
Public trust anchor: the RS256-signed capability document, readable before any request. Returns the decoded payload — a buyer agent can reason over posture/capabilities up front.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'decoded payload', 'firm pricing', 'availability forecast') but do not specify field names, types, or structure. LLMs cannot plan downstream calls or extract data reliably without documented return schemas.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint attributes visible in tool definitions. This prevents clients from inferring safety properties (e.g., which tools are safe to retry, which modify state). Current spec (2026-07-28) recommends these for agent planning.
Error handling guidance absent. Tool descriptions do not explain what errors can occur, how to recover, or what the LLM should do next. E.g., create_intent mentions 'mismatch/stale price is rejected' but does not specify error code, message format, or retry strategy.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | <=2025-11-25 | v2 |
Pagination not visible. discover_products and get_forecast may return large result sets, but no limit, offset, page, or cursor parameters are documented. Without pagination, results could exhaust context windows.
Token parameter exposed. All tools accept 'token' (JWT) as a parameter. While the description notes it is a 'Buyer bearer JWT', best practice is server-side secret injection via environment or vault, not tool parameters. Tokens in parameters risk logging and trace leakage.