Loading ToolBench
MCP server over the Liara cloud documentation: hybrid Persian/English search, page reads, deployment config and build-log diagnosis.
Four well-named tools with clear, actionable descriptions (avg 180 chars, within baseline 194). All tools have input schemas with types and descriptions. Tool names follow verb_noun pattern (search_, read_, platform_, diagnose_). Parameters are well-constrained: search_docs uses max 300 chars, k clamped 1-8; platform_docs uses enum for 15 platforms; diagnose_log limits to 300 lines. Output schemas are documented in descriptions. However, output field structures are not formally specified in JSON Schema, and error handling lacks recovery guidance. No tool annotations (readOnlyHint, etc.) despite all being read-only operations.
Extract the error from a failing build or runtime log and fetch the docs for it. Reduces the log to one error signature — the most specific failure line, not the last one — and returns the documentation pages explaining that class of failure.
Collect the deployment documentation for one platform, ready to write a liara.json. Returns the platform's quick start, deployment and environment-variable pages plus the complete liara.json reference, so every key you write can be cited.
Read one whole documentation page from the local corpus. The URL must be one a previous search returned. No other URL can be fetched: this server has no HTTP client on the tool path and reads only what is already indexed.
Search the Liara documentation and return numbered snippets with their source URLs. Use this for every factual claim about Liara. Write the query in the user's own words plus the product name; Persian and English both work.
Output schemas not formally documented. Tool descriptions explain what is returned (e.g., 'numbered snippets with URLs', 'platform's quick start + deployment + liara.json reference') but no JSON Schema for response objects. LLMs cannot reliably extract fields or plan downstream operations.
No tool annotations despite all four tools being read-only. Missing readOnlyHint=true would signal to agents that these tools are safe to call speculatively without side effects.
Error handling lacks recovery guidance. Code shows results wrapped in ToolResult with explanatory lines, but no examples of how errors guide the LLM to retry or call alternative tools (e.g., 'URL not found in corpus. Try search_docs() first.').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | <=2025-11-25 | v2 |
platform_docs 'needs' parameter accepts arbitrary strings (max 10 items, max 80 chars each) without enum or validation. LLMs may pass invalid requirement names like 'websocket' or 'cron' that don't exist in the corpus, resulting in silent misses.
search_docs parameter 'k' description says 'Values outside that range are clamped' but does not state the default (5) or explain why clamping is better than rejection. LLMs may not understand the behavior.