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.3/5 across 8 of 8 tools scored.
Tools are mostly distinct: FAQ, guides, and listing tools each serve clear purposes. Some overlap between search_listings and get_popular_listings, but descriptions clarify intent.
Most tools use 'get_' prefix for retrieval, but search_listings and search_guides use 'search_'. This minor inconsistency is acceptable given the different operation.
8 tools cover the core functionality without being excessive or sparse. Each tool has a clear role.
The set covers listing search, detail, availability, similar, popular, plus guides and FAQs. Minor gaps like filtering by property type or location radius, but sufficient for common queries.
Available Tools
8 toolsget_faqsAInspect
Get Immoswipe FAQs about using the platform, renting, listing a property, photography/tour services and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Optional audience: "provider" (landlords) or "tenant" | |
| locale | No | ||
| search_by | No | Optional keyword to filter FAQs |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits such as read-only nature, authentication needs, or rate limits. It only states the retrieval action, leaving the agent without important context for invocation.
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, well-structured sentence that conveys the essential information without any unnecessary words, demonstrating excellent conciseness.
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 provides the tool's purpose but lacks details about return format, default behavior with no parameters, and any limitations. For a simple FAQ retrieval tool, this is partially complete.
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 input schema covers 2 of 3 parameters with descriptions, while the tool description adds no additional parameter semantics. Since schema coverage is 67%, the description does not compensate for the missing parameter details.
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 specifies the action (Get) and resource (FAQs) with detailed topics (platform, renting, listing, photography, pricing), making it distinct from sibling tools like get_guide or search_listings.
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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any context or exclusions. It implicitly suggests use for retrieving FAQs but lacks direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_guideAInspect
Read the full Markdown text of a specific Immoswipe guide/blog article by slug (get the slug from search_guides).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug, e.g. "expat-guide-switzerland". Numeric ID also works. | |
| 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 the full burden. It states the core behavior (read full Markdown text), which implies a read-only operation, but does not disclose potential side effects, error handling, or authentication needs. The description is adequate but not rich.
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?
A single, front-loaded sentence encapsulates the tool's purpose and a key workflow hint with no superfluous words. Every part of the description adds value.
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 read tool with 2 parameters and no output schema, the description is mostly complete. It references a companion tool and clearly specifies the input method. It could mention expected output format or error cases, but the core functionality is adequately covered.
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 description does not add meaning beyond the input schema for either parameter. The slug parameter is already well-described in the schema, and the locale parameter has no description in either place. Schema description coverage is only 50%, and the tool description fails to compensate.
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 reads the full Markdown text of a specific guide/blog article by slug. It distinguishes itself from siblings like get_listing_detail and get_faqs by specifying the resource type. The reference to search_guides adds context.
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 a workflow hint by advising to get the slug from search_guides, but it does not explicitly exclude alternatives or state when not to use this tool. However, the purpose is clear enough to differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_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_guidesAInspect
Search Immoswipe blog/guide articles about Swiss housing: renting tips, expat relocation guides, buying advice, deposits, tenancy law. Use for "how to" / advice questions. Returns titles, slugs and links; use get_guide to read the full article.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional keyword to filter articles by title/preview | |
| locale | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool returns titles, slugs, and links, but does not mention pagination, ordering, or behavior when no query is provided. This is adequate for a simple search but lacks some operational details.
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: the first provides the purpose and scope, the second explains the output and suggests a follow-up tool. It is front-loaded with essential information and contains no redundant or extraneous content.
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 its simplicity (two optional parameters, no nested objects, no output schema), the description covers the core functionality and output format well. It could be enhanced by noting default locale behavior or the effect of an empty query, but overall it is sufficiently complete for its 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 50% (only 'query' has a description). The tool description repeats the schema's 'query' info but adds nothing for 'locale', which is only declared with an enum and no description. The description fails to compensate for the missing parameter documentation.
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 searches blog/guide articles about Swiss housing topics, listing specific categories like renting tips and expat guides. It distinguishes from siblings by explicitly telling users to use get_guide to read full articles, and notes the tool returns titles, slugs, and links.
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 using the tool for 'how to' / advice questions, which provides clear context. It also mentions get_guide for reading full content, serving as an alternative. However, it does not explicitly exclude cases where other sibling tools like get_faqs might be more appropriate.
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!