Loading ToolBench
Three well-named tools with strong, detailed descriptions (194 - 250 chars each). All parameters have types and descriptions. Input schemas are complete with Field() annotations. However, output schemas are not formally documented, responses are returned as strings with markdown formatting rather than structured objects. Error handling is minimal (silent failures in autocomplete, generic exception messages). No tool annotations (readOnlyHint, etc.). Naming follows verb_noun pattern (search_, get_) and is clear and distinct. Parameter descriptions are thorough with examples and constraints.
Retrieve a specific article, section (§), or clause (čl.) from a Czech law without downloading the entire document. Use this for targeted lookups within large laws (e.g. Criminal Code §138, Civil Code §1). Returns the article heading and full text with proper formatting. Faster and more focused than get_czech_law_text for single-section queries.
Retrieve the full text of a Czech law, regulation, or legal document as formatted Markdown. Fetches document metadata (citation, status, effective date, ELI identifier) and the complete text content with proper heading hierarchy (Parts, Titles, Sections, Articles). Cross-references to other laws are converted to clickable links. Use the staleUrl from search_czech_legislation results. For very large documents (e.g. Civil Code with 3000+ sections), consider using get_czech_law_article instead to retrieve only the specific section you need.
Search Czech legislation in the e-Sbírka database. Combines autocomplete (exact matches by law number/title) with full-text search (keyword matching across the entire legal corpus). Returns matching documents with their citation codes, titles, validity status, and staleUrl identifiers needed for get_czech_law_text and get_czech_law_article. Results include three categories: - Matching Documents: exact law/regulation matches with permanent staleUrl - Matching Articles/Provisions: specific sections (§) or articles (čl.) with deep links - Full-Text Results: broader keyword matches with status and effective date info
Output schemas not documented. All three tools return `str` (markdown) with no formal schema definition. LLMs cannot parse structured fields or plan downstream calls. Responses should return typed objects (e.g. SearchResult with fields: documents[], articles[], total_count, next_page_token).
Error handling is minimal. search_czech_legislation silently catches exceptions in autocomplete (pass) and returns generic 'Full-text search error: {e}' for failures. No guidance on recovery (e.g., 'Try a simpler query' or 'Check staleUrl format'). Errors should be actionable per pattern:recovery-guide.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint. All three are read-only (safe to retry), but this is not declared. Agents cannot infer safety properties without explicit annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Pagination in search_czech_legislation returns markdown with 'next page' hint text rather than a structured next_cursor or pagination token. LLMs must parse text to extract the next start value, which is error-prone.
Parameter 'max_pages' in get_czech_law_text is numeric with no explicit min/max bounds in schema. Description mentions 'default 30 covers virtually all documents' but does not state hard limits. Should declare min=1, max=100 (or appropriate ceiling) to prevent LLM from passing absurd values.