Loading ToolBench
Harris County (TX) District Clerk civil dockets — every civil case filed in Harris County state district court
Three well-named, read-only tools with strong descriptions (194 - 280 chars) that clearly explain use cases and data limitations. Input schemas are complete with proper types and descriptions. However, output schemas are not documented, and error handling lacks recovery guidance. The 'rolling activity window' caveat is well-communicated in descriptions but not in structured error responses. Tool names follow verb_noun pattern (search_, get_, list_) and are unambiguous. Parameters are well-constrained (enums for role, date ranges, limits). No security issues detected (read-only, no secrets). Composition is clean, three distinct concerns with clear chaining (search → get detail → monitor filings).
Full detail for one Harris County (TX) civil case by its cause number (e.g. "202662585"): case type, status, filing and judgment dates, the style, both sides' attorneys with State Bar numbers, and every party on the case — plaintiffs, defendants, intervenors, registered agents — which the case index alone does not carry. Party locations are city and state. Use after harris_civil_search_party returns a case_number.
Recently filed Harris County (Houston, TX) civil cases, newest first. Returns the same fields as harris_civil_search_party (cause number, court, case type, status, dates, parties, attorneys) but without a search — useful for monitoring new filings or finding cases by filing date alone. Optionally restrict by case_type or a filed-date range.
Find Harris County (Houston, TX) state civil court cases involving a named party — the "is this company being sued, and by whom" question that federal docket sources (court-listener, PACER) structurally cannot answer, because Texas state district court filings are not in them. Matches the party name as a substring against plaintiff, defendant and the clerk's case style, so "KROGER" finds "KROGER TEXAS L.P." and "THE KROGER CO". Optionally restrict to the side the party is on (role=defendant|plaintiff), case_type, or a filed-date range. Returns each case with cause number, court, case type, decoded status, filing and judgment dates, both parties and both attorneys with their Texas State Bar numbers. NOTE the corpus is a rolling activity window: an empty result means no matching case in the ingested window, not that the party has never been sued.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing the response structure. All three tools return shaped case objects but no schema is visible in tool definitions.
Error handling lacks recovery guidance. Tools can fail (network, invalid input, count query swallowed) but descriptions do not explain what the LLM should do next. pgCount() returns null on failure but no tool documents this or suggests retry/fallback.
Pagination limit parameter accepts both number and string types ("limit":{"type":["number","string"]}) but description does not explain the string format or when to use it. This ambiguity invites LLM errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Date parameters (filed_after, filed_before) lack format validation hints in descriptions. LLMs frequently misformat dates (YYYY-DD-MM, epoch, natural language). Description should explicitly state 'ISO 8601 format: YYYY-MM-DD'.
No documented result limits or pagination guidance. harris_civil_search_party and harris_civil_recent_filings accept limit 1 - 100 but descriptions do not explain what happens if results exceed the limit or how to fetch the next page.