immoswipe-ai
Server Details
Search Swiss apartments and houses for rent or sale. Filter by city, price (CHF), rooms, and size.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3/5 across 5 of 5 tools scored.
Each tool has a distinct purpose: get_listing_detail retrieves specific property details, get_popular_listings fetches trending properties, get_reserved_ranges checks availability, get_similar_listings finds comparable properties, and search_listings performs broad searches. No overlap exists in functionality, making tool selection unambiguous for an agent.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_listing_detail, search_listings). The naming convention is uniform throughout, with 'get_' or 'search_' prefixes clearly indicating action types, enhancing predictability and readability.
With 5 tools, the server is well-scoped for a Swiss property listing service. Each tool serves a specific, necessary function without redundancy, providing a balanced set that covers core operations like searching, viewing details, checking availability, and discovering similar or popular listings.
The toolset covers key read-only operations for property listings, including search, detail retrieval, availability checks, and discovery features. However, it lacks write operations (e.g., create/update listings, book properties) or user account management, which might be expected in a full-featured property platform, though the current scope appears focused on querying.
Available Tools
5 toolsget_listing_detailBInspect
Get full details for a specific property by ID. Returns amenities, pricing breakdown, contact info, images.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| listing_id | Yes | Property ID from search results |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return content ('amenities, pricing breakdown, contact info, images'), which adds some context, but fails to address critical aspects like whether this is a read-only operation, error handling, authentication needs, rate limits, or data freshness. For a tool with no annotations, this leaves significant gaps in understanding its 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 highly concise and front-loaded: it states the core purpose in the first clause and lists return values efficiently. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return values, but lacks details on behavioral traits, parameter usage, or error handling. Without annotations or an output schema, more context would be beneficial for a complete understanding, but it meets the bare minimum.
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 50%, with only 'listing_id' documented in the schema. The description adds no explicit parameter information beyond implying 'listing_id' usage. Since coverage is moderate, the baseline is 3, as the description doesn't compensate for the undocumented 'locale' parameter or provide additional semantic context beyond what the schema offers.
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 tool's purpose: 'Get full details for a specific property by ID.' It specifies the verb ('Get'), resource ('property'), and scope ('full details'), though it doesn't explicitly differentiate from siblings like 'get_similar_listings' or 'search_listings' beyond the 'specific property by ID' focus.
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 implies usage context by mentioning 'by ID' and referencing 'search results' in the schema, suggesting this tool is for retrieving details after identifying a property. However, it lacks explicit guidance on when to use this vs. alternatives like 'get_similar_listings' or 'search_listings', and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_popular_listingsCInspect
Fetch the most popular/trending Swiss property listings.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it fetches listings without disclosing behavioral traits such as rate limits, authentication needs, pagination, or what 'popular/trending' means (e.g., based on views, time frame). It lacks critical context for safe and effective use.
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 a single, efficient sentence with zero waste, clearly front-loaded with the tool's purpose. It's appropriately sized for a simple tool, making every word count.
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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address parameters, return values, or behavioral context, making it inadequate for a tool that likely returns complex listing data and has a parameter.
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 0%, so the description must compensate but adds no parameter information. It doesn't mention the 'locale' parameter or explain its purpose (e.g., language for results), leaving semantics undocumented beyond the schema's enum values.
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 ('Fetch') and resource ('most popular/trending Swiss property listings'), providing a specific purpose. However, it doesn't explicitly differentiate from siblings like 'get_similar_listings' or 'search_listings' that might also retrieve listings, missing full sibling distinction.
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 implies usage for trending listings but offers no explicit guidance on when to use this tool versus alternatives like 'search_listings' or 'get_similar_listings'. There are no prerequisites, exclusions, or named alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reserved_rangesCInspect
Check availability/booking dates for a specific property. Returns blocked date ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| to_date | Yes | End date YYYY-MM-DD | |
| from_date | Yes | Start date YYYY-MM-DD | |
| listing_id | Yes | Property ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool returns blocked date ranges, which implies read-only behavior, but doesn't clarify permissions, rate limits, error conditions, or whether it's idempotent. For a tool with 4 parameters and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently convey the core purpose and output. It's front-loaded with the main action and avoids unnecessary elaboration. Every sentence earns its place, though it could be slightly more structured.
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 moderate complexity (4 parameters, no output schema, no annotations), the description covers basic purpose and output but lacks sufficient context. It doesn't explain the relationship between parameters, what 'blocked date ranges' means in practice, or error handling. For a tool checking availability with date ranges, more operational context would be helpful.
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 75% (3 of 4 parameters have descriptions), so the baseline is 3. The description mentions 'specific property' which aligns with listing_id, and 'dates' which aligns with from_date/to_date, but adds no additional semantic context beyond what the schema already provides. The locale parameter isn't addressed in the 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 clearly states the tool's purpose: 'Check availability/booking dates for a specific property' specifies the verb (check) and resource (availability/booking dates). It distinguishes from siblings like get_listing_detail (property details) or search_listings (searching), but doesn't explicitly contrast with them. The second sentence 'Returns blocked date ranges' adds output clarification.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not scenarios, or compare with sibling tools like get_similar_listings or get_popular_listings. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_similar_listingsCInspect
Return listings similar to a given property (same area/category).
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| listing_id | Yes | Property ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns similar listings but doesn't mention any behavioral traits such as rate limits, authentication needs, error handling, or what 'similar' entails beyond area/category (e.g., ranking, limit on results). This leaves significant gaps for a tool with no structured safety or operational hints.
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 a single, efficient sentence that front-loads the core functionality without unnecessary words. Every part of the sentence contributes directly to understanding the tool's purpose, making it highly concise and well-structured.
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 the complexity (a similarity-finding tool with 2 parameters, no annotations, and no output schema), the description is incomplete. It lacks details on behavioral traits, output format, error cases, and doesn't fully compensate for the low schema coverage or missing annotations, making it inadequate for reliable agent use.
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 50% (only 'listing_id' has a description), and the description adds no parameter-specific information beyond implying 'listing_id' is used to find similar properties. It doesn't explain the 'locale' parameter or provide additional context for either parameter, so it partially compensates but doesn't fully address the coverage gap.
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 tool's purpose with a specific verb ('Return') and resource ('listings similar to a given property'), and it specifies the similarity criteria ('same area/category'). However, it doesn't explicitly differentiate from sibling tools like 'get_popular_listings' or 'search_listings', which might also return listings based on different criteria.
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 no guidance on when to use this tool versus alternatives like 'search_listings' or 'get_popular_listings'. It mentions the similarity criteria but doesn't specify prerequisites, exclusions, or comparative contexts, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_listingsBInspect
Search Swiss apartments and houses for rent or sale. Supports city filtering (Zürich, Bern, Basel, Geneva), price (CHF), rooms, and square meters. EXAMPLES: "apartments in Zurich under 2000", "3-room flat in Bern", "house to buy in Basel".
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination | |
| bounds | No | Geographic bounding box: {north, south, east, west} | |
| locale | No | Language: en=English, de=German | |
| per_page | No | Results per page (1-50, default 10) | |
| price_type | No | Transaction type: rent=rentals, sell=purchase, serviced=short-term | |
| address_city | No | Swiss city name. Examples: "Zürich", "Bern", "Basel", "Geneva", "Lausanne". Supports partial matching. | |
| max_sales_price | No | Maximum purchase price in CHF | |
| min_sales_price | No | Minimum purchase price in CHF | |
| max_monthly_price | No | Maximum monthly rent in CHF | |
| max_square_meters | No | Maximum living area in m² | |
| min_monthly_price | No | Minimum monthly rent in CHF | |
| min_square_meters | No | Minimum living area in m² | |
| min_number_of_rooms | No | Minimum number of rooms |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions supported filters but doesn't describe important behaviors: whether this is a read-only operation, how results are returned (format, pagination defaults), error conditions, or rate limits. The examples help but don't cover behavioral traits comprehensively.
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 appropriately concise with two sentences. The first sentence states the purpose and key filters, the second provides helpful examples. No wasted words, though it could be slightly more structured with clearer separation between purpose and usage examples.
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 search tool with 13 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain result format, pagination behavior, error handling, or how multiple filters interact. The examples help but don't compensate for the lack of behavioral context needed for a complex search operation.
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 schema already documents all 13 parameters thoroughly. The description adds minimal value beyond the schema - it mentions city filtering, price, rooms, and square meters, but these are already well-documented in the input schema. The examples provide some context but don't add significant parameter semantics beyond what the schema provides.
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 tool's purpose: 'Search Swiss apartments and houses for rent or sale.' It specifies the resource (Swiss apartments/houses), the action (search), and distinguishes from siblings by focusing on search functionality rather than detail retrieval or popularity metrics.
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 no guidance on when to use this tool versus its siblings (get_listing_detail, get_popular_listings, etc.). While it mentions filtering capabilities, it doesn't explain when this search tool is preferable to alternatives like get_similar_listings or get_popular_listings.
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.
Discussions
No comments yet. Be the first to start the discussion!