Loading ToolBench
A demonstration of OAuth 2.0 integration with MCP servers, consisting of an Authorization Server and a Resource Server that validates tokens via introspection. Supports RFC 9728 Protected Resource Metadata and RFC 8707 resource audience claims.
Two tools with minimal but present descriptions and schemas. Both tools are READ_ONLY, which is good for safety, but definitions lack depth. Tool descriptions are adequate (40-50 chars) but parameter documentation is sparse. Input schemas exist but are either empty (get_time) or minimal (get_dinner_idea with only a single optional string param). No error handling guidance, no output schema documentation, and no details on what the tools actually return or when to use them. The server is primarily a demonstration of OAuth integration, not production-grade tooling. Tool names are reasonable (verb_noun pattern), but lack the richness needed for sophisticated agent planning.
Gets a dinner idea based on context. This tool demonstrates that system information can be protected by OAuth authentication. User must be authenticated to access it.
Get the current server time. This tool demonstrates that system information can be protected by OAuth authentication. User must be authenticated to access it.
get_time has an empty input schema (Input: {}). No parameters are defined or described. This fails the 'every parameter needs a description' rule and makes the tool appear feature-complete but opaque.
Neither tool documents its output schema. LLMs cannot plan downstream tool calls without knowing what fields are returned. A tool that gets dinner ideas should state: returns {idea: string, cuisine: string, estimated_prep_time: int, ...}. Without this, agents cannot reason about the response.
get_dinner_idea parameter 'user_context' lacks specificity. The description says 'Optional context about user preferences, income, etc.' but does not define the format, constraints, or examples of valid input. Should specify: max length, expected fields, or structured format (JSON vs free text).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 6 | - | v1 |
No error handling or recovery guidance. If a tool fails (OAuth token expired, service error, invalid input), the LLM has no actionable next step. Should include patterns like 'If authentication fails, re-authenticate via the OAuth server' or 'If dinner idea generation fails, try with fewer context constraints'.
Tool descriptions do not explain WHEN to use each tool instead of alternatives or what preconditions exist. get_time says 'demonstrates that system information can be protected by OAuth' but does not explain: Does this tool return seconds since epoch or human-readable time? Timezone? Does it require OAuth token refresh before calling?