AI-powered MCP server for analyzing pinuy-binuy (urban renewal) real estate projects in Israel. Provides tools to evaluate building demolition/reconstruction projects, tenant rights, compensation calculations, and project feasibility.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 7 of 7 tools scored.
Most tools target distinct lookups: search, detail, methodology, plan status, registry, recent changes, and top-ranked opportunities. There is some overlap in statutory status returns between get_compound_details, urban_renewal_registry, and planning_status_by_plan, but their descriptions clarify the source and scope enough to avoid major confusion.
The naming mixes verb-led patterns like get_, list_, and search_ with noun-style names like planning_status_by_plan and urban_renewal_registry. It is still readable and mostly predictable, but the lack of a uniform verb_noun convention makes the pattern less consistent.
Seven tools is well-scoped for a domain-specific analyzer server. Each tool addresses a distinct user need, and the count feels neither thin nor bloated.
The surface covers core analysis workflows: searching, retrieving detailed compound data, checking official registry status, inspecting live plan status, seeing recent statutory changes, and finding top mispriced opportunities. Minor gaps exist—like a general list/filter tool or historical comparison—but agents can work around them.
compound_fullAInspectUnified full picture for one Israeli urban-renewal compound: merges the authoritative urban_renewal registry status (Card A), live iplan Xplan statutory detail (Card B: deposit/approval dates + local/district committee), any VATMAL (ות"מל) compounds in the same city, and - when a gush+helka is given - the parcel-level plans (Card E). Identify by mispar (compound number), plan number, city, name, or gush+helka.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Hebrew city name. | |
| gush | No | Block number (גוש) for parcel-level plans. | |
| name | No | Compound name (partial match ok). | |
| plan | No | Plan number, e.g. "506-1047059". | |
| helka | No | Parcel number (חלקה), with gush. | |
| mispar | No | Compound number (MisparMitham). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool merges multiple data sources, includes live statutory details with dates and committees, and conditionally includes parcel-level plans only when gush+helka is provided. This gives the agent meaningful expectations about scope and conditional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the core purpose ('Unified full picture') and then enumerates the merged components and accepted identifiers. The long single-sentence structure and unexplained references to Card A/B/E make it slightly harder to parse quickly, but every part contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers both inputs and outputs at a practical level: what data sections will be returned and the identifier alternatives. It does not explicitly state that at least one identifier is required even though the schema marks all six parameters as optional, and it leaves some ambiguity about whether city alone can identify a single compound. Still, it is largely complete for an aggregation tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all six parameters clearly. The description adds the notion that identification can happen via any of several identifiers and that gush+helka triggers parcel-level plans, but these are largely implied by the parameter names and schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an aggregator for one Israeli urban-renewal compound, specifying the exact data sources merged: registry status, iplan statutory detail, VATMAL compounds, and parcel-level plans. This distinguishes it from the narrower sibling tools such as urban_renewal_registry, vatmal_compounds, planning_by_parcel, and planning_status_by_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as providing the 'unified full picture' for a single compound, which makes the primary use case clear. It does not name alternatives or state when not to use it, but the aggregation language implies this is the comprehensive option rather than a specific single-source lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_compound_detailsAInspectReturn full per-field details for one pinui-binui compound by slug or numeric id. Use when user wants to drill into a specific compound (e.g. "tell me more about קהילת קליבלנד").
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes | Compound slug (preferred) or numeric id as string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It indicates a read operation and scope ('full per-field details'), but lacks specifics on authentication, rate limits, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description covers invocation and purpose. Could optionally mention that details are 'per-field', but overall complete given lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The description adds usage context ('by slug or numeric id') and an example, but does not significantly enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return full per-field details') and the resource ('one pinui-binui compound'), distinguishing it from sibling tools like search_compounds or list_top_mispriced_compounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when user wants to drill into a specific compound') with an example, but does not provide exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_methodologyAInspectReturn the QUANTUM scoring methodology, statutory weights, citation patterns, refusal list, and live data endpoint URLs. Use first when an AI agent or user is unfamiliar with QUANTUM or needs to cite QUANTUM properly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the tool's behavior: it returns methodology, weights, patterns, refusal list, and URLs. With zero parameters and a read-only nature (implied by 'Return'), the description covers all relevant behavioral traits without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the key purpose in the first sentence, and contains zero filler. Every word contributes to understanding the tool's function and recommended usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description thoroughly enumerates the returned data (methodology, weights, citations, refusal list, endpoints). It also provides usage context ('Use first when...'), making it self-sufficient for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% by default. The description adds meaningful context by listing the specific data categories returned (e.g., 'statutory weights', 'citation patterns'), which compensates for the lack of parameters and justifies a baseline-adjusted score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns 'QUANTUM scoring methodology, statutory weights, citation patterns, refusal list, and live data endpoint URLs.' This specific verb+resource combination clearly distinguishes it from sibling tools like 'get_compound_details' or 'search_compounds', which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct guidance: 'Use first when an AI agent or user is unfamiliar with QUANTUM or needs to cite QUANTUM properly.' It implicitly excludes use cases where the user already knows the methodology or needs compound-level data, though it doesn't explicitly list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recent_statutory_changesAInspectReturn pinui-binui compounds that transitioned to a new statutory stage (declared, deposited, approved, permit, construction) within the last N days. Use when user asks "what changed recently" or "any new pinui-binui approvals".
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses tool is read-only (returns data), specifies time window and stages. No contradictions. Lacks output format details but sufficient for expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states action and scope, second gives example queries. No unnecessary words. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, description is mostly complete. Covers what, when, and example use. Lacks output format or ordering details, but acceptable for a list utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'days' explained as 'within the last N days' in description, adding meaning beyond schema. Schema coverage is 0%, so description compensates adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it returns compounds transitioning to new statutory stages within N days. Uses specific verb 'Return' and lists stages. Distinguishes from siblings by focusing on recent changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when user asks what changed recently or any new approvals.' Provides clear context without explicitly listing alternatives, but siblings imply different uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_top_mispriced_compoundsAInspectReturn the current top Israeli pinui-binui compounds ranked by QUANTUM Mispricing Score = premium_gap * count(active_listings) * statutory_certainty. Use when the user asks for "top pinui-binui opportunities", "most undervalued pinui-binui compounds", "Israeli urban renewal arbitrage", or any variant. Results are regenerated hourly from the QUANTUM analyzer database.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum compounds to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses hourly regeneration and formula, which is sufficient for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that efficiently cover purpose, usage, and transparency with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers purpose, usage, and update frequency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter description for 'limit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns 'top Israeli pinui-binui compounds ranked by QUANTUM Mispricing Score' using a specific formula, distinguishing it from siblings like get_compound_details or search_compounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios ('top pinui-binui opportunities', 'most undervalued pinui-binui compounds', etc.), though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
planning_by_parcelAInspectParcel-level statutory planning for a specific building/parcel. Resolves a gush + helka (block + parcel) to its location via the govmap cadastre, then returns the iplan Xplan plans covering that exact parcel (status, deposit/approval dates, committees). Use for a single building that is not necessarily inside a declared compound.
| Name | Required | Description | Default |
|---|---|---|---|
| gush | Yes | Block number (גוש). | |
| helka | Yes | Parcel number (חלקה). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the underlying resolution via 'govmap cadastre' and the returned fields (status, dates, committees), but does not state safety (read-only), failure behavior for invalid gush/helka, or other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first delivers the core workflow, the second the usage guidance. No filler or repetition of schema property names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter lookup with no output schema, it explains the return contents (status, deposit/approval dates, committees) and the use case, which is largely sufficient. It omits edge cases (e.g., no plans found, invalid block/parcel) but those are minor given the siblings provide a clear selection context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic labels ('Block number', 'Parcel number'). The description adds meaning by explaining that gush+helka are resolved together via the cadastre to locate the parcel, which clarifies the combined semantic role beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('resolves' and 'returns') with a precise resource: iplan Xplan plans covering an exact parcel. It also distinguishes itself from compound-focused siblings by noting it is for 'a single building that is not necessarily inside a declared compound.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives clear when-to-use context ('Use for a single building that is not necessarily inside a declared compound'). It does not explicitly name alternative tools or state when not to use, but the compound exclusion implies a boundary against compound-level siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
planning_status_by_planAInspectLive statutory detail for a specific plan from the iplan "תכנון זמין" / Xplan system: current status, deposit and approval dates, district + local committee, approving authority, and authorized-unit counts. Query by plan number, or by ITM (wkid 2039) point to get every plan covering that location.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ITM easting (with y) for a point-in-polygon query. | |
| y | No | ITM northing (with x). | |
| plan_number | No | Plan number, e.g. "507-0177683". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does add useful behavioral context: the data is 'live', and a point query returns every covering plan. However, it does not state whether the operation is read-only, how results are shaped, whether plan_number and x/y are exclusive, or any error/limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler: the first states what the tool returns, and the second explains the two query modes. The most important usage information is front-loaded and every phrase contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, key outputs, and both query modes well. However, with no annotations and no output schema, it should more explicitly state that at least one query path must be supplied, that plan_number and x/y are alternatives, and what the response format or edge cases look like. These gaps could confuse an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds extra meaning by specifying the ITM coordinate reference as wkid 2039 and clarifying that x/y form a point-in-polygon query returning all plans covering that location. This goes beyond the schema's terse field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource (a statutory plan from the iplan/Xplan system) and enumerates the returned details: status, dates, committees, approving authority, and unit counts. It also clarifies the secondary point-query behavior. It does not explicitly distinguish from siblings, but the specific resource and output fields make the purpose sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage modes: query by plan_number, or query by an ITM point (x/y) to retrieve all plans covering that location. This is clear context for when to use each parameter combination. It does not name sibling alternatives, but none of the listed siblings are obviously in the same statutory-plan domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_compoundsAInspectKeyword search across QUANTUM-tracked pinui-binui compounds by compound name, city, or neighborhood. Use when user asks about a specific compound or area.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional Hebrew city name filter (e.g. "תל אביב", "רמת גן"). | |
| limit | No | ||
| query | Yes | Search query (Hebrew or English). Matched against compound name, city, neighborhood. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the search scope and fields, but omits details on pagination, result limits, error behavior, or whether the search is fuzzy/exact. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and provide usage guidance. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and usage but lacks behavioral details (pagination, sorting, error handling, output structure) that would help an agent use the tool reliably, especially given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (query and city have descriptions, limit does not). The tool description paraphrases the query parameter's matching fields but adds no new semantics for city or limit. It does not compensate for the missing limit description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'search', the resource 'QUANTUM-tracked pinui-binui compounds', and the search fields 'compound name, city, or neighborhood'. It distinguishes itself from sibling tools like get_compound_details by focusing on keyword-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use when user asks about a specific compound or area', providing clear context. However, it does not explicitly exclude cases where a compound ID is known or mention sibling tools like get_compound_details as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
urban_renewal_registryAInspectAuthoritative statutory status for declared Israeli pinui-binui compounds, sourced from the Government Authority for Urban Renewal registry (data.gov.il). Returns compound number, name, city, official status, plan number, declaration date, unit counts, permits, and MAVAT/govmap deep-links. Use to confirm a compound is officially declared and at what statutory stage.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Hebrew city filter (e.g. "רמת גן"). | |
| limit | No | ||
| mispar | No | Compound number (MisparMitham) for an exact lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden, and it does well by disclosing the authoritative data source, the fact that it returns a defined set of status-related fields, and the confirm-only purpose. It does not mention pagination/limit behavior, possible status values, or data freshness, which would make the behavior fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver source, authority, output fields, and intended use with no filler. The key scoping phrase 'authoritative statutory status' is front-loaded, making the tool easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by listing the returned fields and the statutory-purpose framing. Given the simple optional-parameter input schema, the main omission is not explaining default behavior when no parameters are supplied or how this differs from search_compounds.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: city and mispar are described in the schema, and the description adds little parameter-specific meaning beyond mentioning compound number as a return field. The limit parameter is not described in either the schema or the description, though its type, default, min, and max are given in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a lookup of authoritative statutory status for Israeli pinui-binui compounds from the government registry, and lists the concrete fields returned. It does not explicitly contrast itself with siblings like search_compounds or get_compound_details, missing the explicit differentiation needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives an explicit use case: confirm a compound is officially declared and at what statutory stage. However, it does not state when not to use this tool or name an alternative tool for related lookups, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vatmal_compoundsAInspectList declared Israeli VATMAL (ות"מל — preferred-housing) urban-renewal complexes from the iplan vatmal_mitchamim_muchrazim layer: tamal plan number, compound name, city, district, submitter, planned units, area, declaration date. Filter by city or tamal number. Use for the ות"מל fast-track pipeline specifically.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Hebrew city filter (e.g. "רמת גן"). | |
| limit | No | ||
| tamal | No | VATMAL plan-number filter (e.g. "1001"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it clearly frames the operation as a read-only listing scoped to a declared layer. It also discloses the available filters and output fields. It does not discuss pagination or rate limits, but the schema's limit parameter mitigates the main gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the action and resource, then packs the output fields into a compact colon-separated list. Every sentence earns its place, and there is no filler or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-filter list tool with no output schema, the description covers the source layer, return fields, filters, and intended use case. Minor ambiguity remains about whether city and tamal combine and what happens when neither filter is provided, but these are small gaps for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents city and tamal, covering 67% of parameters; the description mostly rephrases this as 'Filter by city or tamal number' and clarifies that tamal refers to a plan number. It adds nothing meaningful about the limit parameter, so it does not go beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List declared Israeli VATMAL ... complexes from the iplan vatmal_mitchamim_muchrazim layer' and enumerates the exact fields returned. This clearly distinguishes it from sibling tools focused on details, search, methodology, or statutory changes, and the 'fast-track pipeline' phrase marks its niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: 'Use for the ות"מל fast-track pipeline specifically,' which helps an agent know when to prefer this tool. It does not name alternative tools or state when not to use it, so it stops short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
