Skip to main content
Glama
barvhaim

Israeli Land Authority MCP Server

by barvhaim

get_tender_map_details

Retrieve geographic coordinates and mapping data for Israeli Land Authority tenders to identify precise locations and enable map integration.

Instructions

Get geographic and mapping data for a specific tender

Returns location coordinates and map integration data for the specified tender.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The MCP tool handler function decorated with @mcp.tool() that implements get_tender_map_details. It calls the API client to fetch map details and wraps the response in a success/error structure.
    @mcp.tool()
    def get_tender_map_details(args: TenderDetailsArgs) -> Dict[str, Any]:
        """
        Get geographic and mapping data for a specific tender
    
        Returns location coordinates and map integration data for the specified tender.
        """
        try:
            map_details = api_client.get_tender_map_details(args.michraz_id)
            return {
                "success": True,
                "tender_id": args.michraz_id,
                "map_details": map_details,
            }
        except Exception as e:
            return {"success": False, "error": str(e), "tender_id": args.michraz_id}
  • Pydantic input schema (TenderDetailsArgs) used by the get_tender_map_details tool, requiring a single integer michraz_id (tender ID).
    class TenderDetailsArgs(BaseModel):
        """Arguments for tender details tools"""
    
        michraz_id: int = Field(..., description="The tender ID to get details for")
  • Helper method in IsraeliLandAPI client that performs the actual HTTP request to fetch tender map details from the Israeli Land Authority API.
    def get_tender_map_details(self, michraz_id: int) -> Dict[str, Any]:
        """
        Get geographic/mapping data for a tender
    
        Args:
            michraz_id: The tender ID to get map details for
    
        Returns:
            Dictionary containing map details
        """
        self._rate_limit()
    
        try:
            response = self.session.get(
                f"{self.BASE_URL}/MichrazDetailsApi/GetMichrazMapaDetails",
                params={"michrazID": michraz_id},
                timeout=30,
            )
            response.raise_for_status()
            return response.json()
        except requests.exceptions.RequestException as e:
            raise Exception(
                f"Failed to get map details for tender ID {michraz_id}: {str(e)}"
            )
  • Registration point in the main server setup where register_tools is called. This indirectly registers get_tender_map_details via the chain: register_tools -> register_tender_tools -> @mcp.tool() decorator.
    # Register tools and resources
    register_tools(mcp, api_client)
    register_resources(mcp)
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool returns 'location coordinates and map integration data' but doesn't describe format, accuracy, or limitations. It doesn't mention whether this is a read-only operation, potential rate limits, authentication needs, or error conditions. For a tool with no annotations, this leaves significant behavioral gaps.

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

Conciseness4/5

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

The description is appropriately concise with two sentences that efficiently state purpose and return values. The first sentence clearly establishes what the tool does, and the second specifies the output. There's no wasted text, though it could be slightly more structured with explicit separation of purpose and behavior.

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 has an output schema (which handles return value documentation), the description's job is lighter. It adequately covers the core purpose and output types. However, for a tool with no annotations and 0% schema parameter coverage, it should ideally provide more parameter guidance and behavioral context to be fully complete.

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

Parameters3/5

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

Schema description coverage is 0% (the parameter 'michraz_id' has no description in the schema), but the description doesn't compensate by explaining the parameter. It mentions 'for the specified tender' which implies a tender identifier is needed, but doesn't clarify what 'michraz_id' represents or provide format examples. With one undocumented parameter and no compensation in the description, this meets the baseline for minimal viability.

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 geographic and mapping data for a specific tender' specifies the verb (get), resource (geographic and mapping data), and scope (for a specific tender). It distinguishes from siblings like 'get_tender_details' by focusing on geographic/mapping aspects rather than general details. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate versus 'get_tender_details' (which might return different data) or 'search_tenders' (which might find tenders before getting map details). There's no context about prerequisites or exclusions, leaving the agent to guess based on tool names alone.

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