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.2/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: compound details, methodology, recent changes, top mispriced, and search. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (e.g., get_compound_details, list_recent_statutory_changes). Uniform style.
Five tools is well-scoped for a niche domain like pinui-binui analysis, covering key operations without excess.
Covers searching, details, methodology, recent changes, and top opportunities. Minor gap: no comparison or filtering tools, but core workflows are present.
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.
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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!
