Skip to main content
Glama
barvhaim

Israeli Land Authority MCP Server

by barvhaim

get_kod_yeshuv

Retrieve official Israeli settlement codes from Hebrew names for integration with government systems.

Instructions

Get Kod Yeshuv (settlement code) from Hebrew settlement name

Returns the official settlement code used by Israeli authorities for the given settlement name. Useful for integration with other Israeli government systems.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The get_kod_yeshuv tool handler: searches for exact and partial matches in KOD_YESHUV_SETTLEMENTS data, returns settlement code or partial matches.
    @mcp.tool()
    def get_kod_yeshuv(args: KodYeshuvArgs) -> Dict[str, Any]:
        """
        Get Kod Yeshuv (settlement code) from Hebrew settlement name
    
        Returns the official settlement code used by Israeli authorities for the given
        settlement name. Useful for integration with other Israeli government systems.
        """
        try:
            # Search for exact match first
            settlement_name = args.settlement_name.strip()
    
            for settlement in KOD_YESHUV_SETTLEMENTS:
                if settlement.name_hebrew == settlement_name:
                    return {
                        "success": True,
                        "settlement_name": settlement_name,
                        "kod_yeshuv": settlement.kod_yeshuv,
                        "match_type": "exact",
                    }
    
            # Search for partial matches if no exact match found
            partial_matches = []
            settlement_lower = settlement_name.lower()
    
            for settlement in KOD_YESHUV_SETTLEMENTS:
                name_lower = settlement.name_hebrew.lower()
                if settlement_lower in name_lower or name_lower in settlement_lower:
                    partial_matches.append(
                        {
                            "settlement_name": settlement.name_hebrew,
                            "kod_yeshuv": settlement.kod_yeshuv,
                            "similarity": "partial",
                        }
                    )
    
            if partial_matches:
                return {
                    "success": True,
                    "searched_name": settlement_name,
                    "exact_match": False,
                    "partial_matches": partial_matches[:10],  # Limit to top 10 matches
                    "match_type": "partial",
                }
    
            # No matches found
            return {
                "success": False,
                "error": f"No settlement found matching '{settlement_name}'",
                "searched_name": settlement_name,
                "suggestion": "Try using the exact Hebrew name or check the settlement name spelling",
            }
    
        except Exception as e:
            return {
                "success": False,
                "error": str(e),
                "searched_name": args.settlement_name,
            }
  • KodYeshuvArgs Pydantic model defining the required 'settlement_name' (Hebrew string) input parameter.
    class KodYeshuvArgs(BaseModel):
        """Arguments for settlement code lookup"""
    
        settlement_name: str = Field(
            ..., description="Settlement name in Hebrew to get the Kod Yeshuv for"
        )
  • Registers settlement tools by calling register_settlement_tools(mcp, api_client), which defines and registers get_kod_yeshuv via @mcp.tool().
    from .tender_tools import register_tender_tools
    from .settlement_tools import register_settlement_tools
    
    
    def register_tools(mcp, api_client):
        """Register all MCP tools"""
        register_tender_tools(mcp, api_client)
        register_settlement_tools(mcp, api_client)
  • Top-level call to register_tools(mcp, api_client) which chains to settlement tools registration including get_kod_yeshuv.
    register_tools(mcp, api_client)
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 describes the core behavior (lookup/translation) and mentions the integration use case, but doesn't disclose error handling, rate limits, authentication needs, or what happens with invalid inputs. It adds some context but leaves significant 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 perfectly structured with two focused sentences: the first states the core functionality, the second explains the practical application. Every word earns its place with zero redundancy or unnecessary elaboration.

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 simple nature (single parameter lookup), the presence of an output schema (which handles return values), and the clear purpose statement, the description is reasonably complete. However, it could benefit from mentioning potential edge cases or error scenarios for a tool with no annotations.

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?

With 0% schema description coverage and only 1 parameter, the description compensates well by explaining the parameter's purpose ('Hebrew settlement name to get the Kod Yeshuv for') and context. It adds meaningful semantics beyond what the bare schema provides, though it doesn't specify format requirements or character encoding details.

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

Purpose5/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 with specific verb ('Get') and resource ('Kod Yeshuv'), and distinguishes it from sibling tools by focusing on settlement code lookup rather than tender-related operations. It explains what the tool does in concrete terms: converting Hebrew settlement names to official settlement codes.

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

Usage Guidelines4/5

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

The description provides clear context about when to use this tool ('for integration with other Israeli government systems'), but doesn't explicitly state when NOT to use it or mention alternatives. It distinguishes from siblings by focusing on settlement codes rather than tenders, though not through explicit comparison.

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/barvhaim/remy-mcp'

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