Loading ToolBench
A voice-enabled MCP assistant using FastRTC for speech-to-text and text-to-speech, with integration to MCPO (MCP OpenAI Protocol) adapter for accessing MCP tools like time and Airbnb services
FastRTC MCPO Voice Assistant has three tools with reasonable names and basic descriptions, but critical gaps in schema documentation, parameter descriptions, and output specifications prevent higher scoring. Tool definitions appear to be inferred from code rather than explicitly registered with full schemas. No evidence of input validation, error handling guidance, or output schema documentation. The server lacks structured tool registration mechanisms and relies on external MCPO adapter (ollama-mcpo-adapter) whose implementation is not visible, preventing assessment of actual schema compliance.
Search Airbnb listings with various filters and parameters
Convert time between different timezones
Get the current time in a specified timezone
Output schemas completely undocumented. No visible schema definition for return values. Code references 'searchResults', 'datetime', 'is_dst' fields but these are inferred from code logic, not formally specified. LLMs cannot plan downstream operations without knowing expected response structure.
Parameter descriptions lack actionable format constraints. 'timezone' param says 'e.g., Europe/London' but no formal timezone format specification, range validation, or enum list. 'checkInDate' and 'checkOutDate' mention YYYY-MM-DD format only in description text, no regex pattern or JSON Schema format constraint. LLMs will hallucinate invalid timezones and date formats.
airbnb_search tool name lacks clarity on scope. Does 'search' return filtered listings, availability, prices, or all three? Tool does not clearly specify whether it queries real Airbnb API or mock data. 'roomType' parameter example 'Entire home/apt' mixes enum values into description, should be a formal enum list.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling guidance. Code contains generic exception handling ('Error formatting Airbnb results: {e}') but no user-facing error messages or recovery instructions. If timezone is invalid, API returns 500, or Airbnb endpoint fails, LLM receives no actionable guidance on what to do next.
Tool definitions appear inferred rather than explicitly registered. Code shows tool initialization via 'initialize_mcpo_tools()' calling MCPO adapter, but actual schema registration is delegated to external ollama-mcpo-adapter library. Cannot verify that tool names, descriptions, and schemas match MCP specification without seeing adapter source.
airbnb_search likely violates rate limits and context window best practices. Code mentions 'top 3' in formatting but tool description does not specify result limit. If API returns 500+ listings, they will all be passed to LLM, bloating context and degrading reasoning. Tool should document and enforce a reasonable cap (20 - 50 results).
No pagination support documented. 'airbnb_search' accepts no offset, cursor, or limit parameters visible in schema. Multi-day Airbnb searches across price ranges can return hundreds of listings, without pagination, agents cannot efficiently narrow results or iterate through large result sets.
Numeric parameters lack explicit min/max bounds. 'guests' and 'minPrice'/'maxPrice' have no documented constraints. Can an agent pass guests=0? guests=1000? minPrice=-100? maxPrice=999999? Unbounded numeric inputs let LLMs pass absurd values.