Skip to main content
Glama

get_legal_statuses

Retrieve all legal act status types like active, repealed, or consolidated to classify and filter Polish legal documents from Dziennik Ustaw and Monitor Polski.

Instructions

Get all possible legal act statuses (active, repealed, consolidated, etc.) for document classification and filtering.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • app.py:689-723 (handler)
    The main handler function that executes the tool logic for get_legal_statuses. It makes an API request to fetch the list of all possible legal act statuses from the Sejm API and returns them as a list of strings, handling errors gracefully.
    def get_statuses_list() -> list[str]:
        """Fetches a list of all possible legal act statuses.
    
        Retrieves the complete vocabulary of legal act statuses used in the Polish legal system,
        including active, repealed, consolidated, and other status classifications. This is
        essential for filtering and understanding the current legal standing of documents.
    
        Returns:
            list[str]: List of status strings in Polish, representing all possible legal act statuses.
                       Returns empty list if request fails.
    
        Examples:
            User asks: "What are the possible act statuses?":
                Returns: ['akt indywidualny', 'akt jednorazowy', 'akt objęty tekstem jednolitym', ...]
            User asks: "Show me all legal act status types":
                Returns: ['obowiązujący', 'uchylony', 'wygaśnięcie aktu', ...]
            User asks: "What statuses can a Polish law have?":
                Returns: ['akt obowiązujący', 'akt uchylony', 'tekst jednolity', ...]
            User asks: "List all possible statuses for legal documents":
                Returns: ['aktywny', 'nieaktywny', 'zmieniony', ...]
            User asks: "What are the different states a law can be in?":
                Returns: ['obowiązujący', 'uchylony', 'wygaśnięty', ...]
        """
        logger.debug("get_statuses_list called")
        try:
            url = "https://api.sejm.gov.pl/eli/statuses"
            response = requests.get(url, headers={"Accept": "application/json"})
            response.raise_for_status()
    
            data = response.json()
            logger.info(f"get_statuses_list retrieved {len(data)} statuses")
            return data
        except Exception as e:
            logger.error(f"Error: {e}")
            return []
  • app.py:684-688 (registration)
    The registration of the get_legal_statuses tool using the @app.tool decorator, specifying the name, description, and tags.
    @app.tool(
        name="get_legal_statuses",
        description="Get all possible legal act statuses (active, repealed, consolidated, etc.) for document classification and filtering.",
        tags={"metadata", "statuses", "reference", "legal-analysis"}
    )
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that this is a retrieval operation ('Get all possible') and hints at behavioral traits by mentioning it returns statuses for 'classification and filtering'. However, it doesn't specify whether this is a static list or dynamically updated, whether there are rate limits, authentication requirements, or what format the output takes. The description adds some context but leaves important behavioral aspects unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that efficiently communicates the tool's purpose and context. Every word earns its place: 'Get all possible legal act statuses' establishes the core function, '(active, repealed, consolidated, etc.)' provides concrete examples, and 'for document classification and filtering' adds valuable usage context without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, 100% schema coverage, has output schema), the description is reasonably complete. It clearly states what the tool returns and why one would use it. The existence of an output schema means the description doesn't need to detail return values. However, for a tool with no annotations, it could benefit from more behavioral context about the nature of the status list (static vs. dynamic, update frequency, etc.).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't waste space discussing parameters, and the baseline for this situation is 4. No additional parameter semantics are needed or provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get all possible legal act statuses' with specific examples like 'active, repealed, consolidated'. It distinguishes from siblings by mentioning 'for document classification and filtering', which suggests a metadata retrieval function rather than content retrieval like get_act_content or search_legal_acts. However, it doesn't explicitly differentiate from get_legal_types or get_legal_keywords which might serve similar classification purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through 'for document classification and filtering', suggesting this tool is used when needing status metadata for organizing or filtering legal acts. However, it doesn't provide explicit guidance on when to use this versus alternatives like get_legal_types or get_legal_keywords, nor does it mention prerequisites or exclusions. The guidance is present but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/numikel/law-scrapper-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server