Loading ToolBench
MCP server for monitoring and fetching Polish law acts published by the Polish Sejm, filtering them by topic, and summarizing their content using an LLM.
Law Scrapper MCP demonstrates solid definition quality with well-structured parameter schemas, consistent naming conventions using action verbs, and comprehensive descriptions across all 13 tools. All tools follow verb_noun naming patterns (search_*, browse_*, get_*, read_*, analyze_*, track_*, compare_*, etc.). Input schemas are fully defined with proper types, enums, and descriptions for all parameters. However, there are gaps in output schema documentation and error handling guidance. The server accepts pagination (limit/offset), supports enums for constrained inputs (Publisher, DetailLevel, MetadataCategory, RelationshipType), and includes parameter descriptions. Missing: explicit output schemas for tool responses, error classification guidance, and recovery hints in descriptions. Tool composition is sound, each tool has a single clear responsibility, and chaining is supported through consistent ID references (eli parameter used across multiple tools).
Analyze relationships between legal acts (amendments, repeals, legal basis)
Browse all legal acts from a specific year and publisher
Calculate legal dates by adding or subtracting days, months, and years from a base date
Compare metadata of two legal acts (titles, statuses, dates, keywords)
Filter a stored result set using regex patterns and other criteria
Retrieve detailed information about a specific legal act, optionally loading its full content
Retrieve system metadata such as available keywords, document types, statuses, and publishers
Output schemas are not documented in source. While input schemas are comprehensive, there is no visible documentation of what fields tools return, preventing LLMs from planning downstream tool calls effectively.
Error handling lacks recovery guidance. Tool descriptions do not include what errors might occur, how to classify them (retryable vs. user-fixable), or what the LLM should do next.
filter_results tool has weak naming. 'filter_results' is vague about what it filters. Better: 'filter_legal_act_results' to clarify it operates on previously-stored search results, not generic data.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
List all documents currently loaded in the document store
List all active result sets stored in memory from previous search operations
Read specific sections of a loaded legal act, or return the table of contents when section is omitted
Search for terms within a loaded legal act with context around matches
Search for Polish legal acts by keywords, type, dates, and status
Track changes and new acts within a date range, optionally filtered by keywords
Stateful result sets and document store design. Tools like list_result_sets, filter_results, and read_act_content rely on in-memory state (result_set_id, eli references to loaded documents). This violates stateless request handling (current MCP spec 2026-07-28). Each request should be self-contained.
Descriptions for list_result_sets and list_loaded_documents are too brief (70 chars). Should explain what these tools reveal, when to call them, and why an agent would use them (discovery/debugging). Expand to 100-150 chars with use-case context.
calculate_legal_date lacks context on why an LLM would call it. Description does not explain when to use this vs. built-in date math. Add: 'Use when Polish legal deadlines require date calculations respecting Polish holidays (Easter, etc.), raw date math may not account for jurisdiction-specific rules.'