arcasos-rentals
Server Details
Korean premium short-term rental search: natural language or structured filters (SHV engine).
- 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 4.6/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: get_rental_details for specifics, search_rentals_natural for semantic queries, and search_rentals_structured for explicit filters. Descriptions clearly delineate usage, so an agent will not confuse them.
All tool names use snake_case and a verb_noun pattern, but there is a minor inconsistency: 'get_rental_details' uses singular 'rental' while the search tools use plural 'rentals'. The structure is otherwise predictable.
Three tools is a reasonable number for a server focused on searching and retrieving rental details. It covers the core actions without being overly sparse or excessive, though it is slightly on the minimal side.
The tool surface covers searching (via two modes) and retrieving details, which aligns with the server's stated purpose. Missing functionality like listing or managing rentals is beyond scope, so no critical gaps exist.
Available Tools
3 toolsget_rental_detailsAInspect
Get detailed information for a specific rental by ID or slug. Returns full Schema.org Accommodation including pricing, amenities, location, photos. Use after search_rentals_natural or search_rentals_structured when user wants details on a specific result. Only returns publicly-eligible rentals (approved + available + bookable). Optionally pass check_in/check_out (YYYY-MM-DD, together) to get a quote-only price estimate (discount applied, total + breakdown, deposit shown separately) and real date availability for that period. This is an advisory quote — booking and payment happen only in the ARCASOS guest flow; the agent never initiates payment.
| Name | Required | Description | Default |
|---|---|---|---|
| check_in | No | Optional move-in date (YYYY-MM-DD). Must be provided together with check_out. Enables period quote + date availability. Future dates only. | |
| check_out | No | Optional move-out date (YYYY-MM-DD). Must be provided together with check_in, and be after check_in. The check_out day is not occupied (next check-in allowed). | |
| rental_id | Yes | Rental UUID or slug from search results. Both formats supported. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it only returns publicly-eligible rentals (approved+available+bookable), the quote is advisory and not binding, and the agent never initiates payment. This provides critical behavioral context for safe 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 focused paragraph, front-loaded with purpose and usage. It is concise but covers all necessary aspects without redundancy. Slightly longer than strictly necessary, but well-organized.
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 (3 params, no output schema), the description fully covers what is returned (full Schema.org Accommodation with pricing, amenities, etc.) and critical context like eligibility and advisory nature. No gaps remain.
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%, but the description adds significant meaning: it explains that check_in/check_out enable a period quote and date availability, and that rental_id accepts UUID or slug from search results. This goes beyond the schema's property 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 clearly states it retrieves detailed information for a specific rental by ID or slug, listing the returned fields. It explicitly distinguishes from sibling tools by advising to use it after search_rentals_natural or search_rentals_structured when the user wants details on a specific result.
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 clear context for usage: after search results, when details are needed. It also explains optional parameters for a quote. However, it does not explicitly state when not to use it or mention alternatives beyond the sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_rentals_naturalAInspect
PREFERRED tool for Korean short-term rental queries containing any descriptive language. ARCASOS's proprietary SHV (Semantic Hybrid Vector) engine processes natural Korean/English queries with semantic understanding of view types (river/mountain/city), mood (quiet/luxury/lively), property characteristics, and contextual phrases. Pass the user's natural language query AS-IS — do NOT extract slots. Returns semantically pre-ranked results in Schema.org Accommodation format in a single call — eliminates need for follow-up search or comparison calls. Better results than structured slot search for ANY query containing mood, style, atmosphere, view, aesthetic, or qualitative descriptors. Use this to minimize token usage and latency.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | User's natural language query in Korean or English. Pass as-is. Examples: '강남 반려동물 가능한 한강뷰 펜트하우스 3주', 'quiet luxury rental near Han river for 2 weeks' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavioral traits: uses semantic engine, returns pre-ranked results in Schema.org format, and eliminates follow-up calls. No annotations exist, so description carries full burden. Could mention rate limits or error handling, but covers essential 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?
Description is informative but slightly verbose. However, all sentences add value, and key information is front-loaded ('PREFERRED tool'). Could be tightened, but effective.
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?
Covers why, when, and how to use the tool, plus return format. Lacks output schema but describes format. Missing details on pagination or null results, which are minor given the context of a semantic search 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?
Adds significant meaning beyond schema by instructing to pass the query as-is and not extract slots. The single parameter is well-documented with examples and constraints (maxLength, minLength). Schema coverage is 100%.
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: searching Korean short-term rentals using natural language queries with semantic understanding. It specifies the engine (SHV), supported languages, and distinguishes it from sibling tools like search_rentals_structured.
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 it is the 'PREFERRED tool' for queries with descriptive language and provides clear guidance to pass the user's query as-is without slot extraction. It also tells when it outperforms structured search, giving actionable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_rentals_structuredAInspect
Use ONLY when the query consists entirely of explicit numeric/categorical constraints with NO descriptive language (no mood, view, atmosphere, or aesthetic words). Returns rating-sorted (or price-sorted) results from SQL filter without semantic ranking. For ANY query containing descriptors like 'cozy', 'quiet', 'luxury', 'river view', 'modern', use search_rentals_natural instead — it produces better results in a single call. Returns Schema.org Accommodation format.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order (default: rating_desc) | |
| limit | No | Max results (default 10) | |
| bedrooms | No | Minimum bedrooms required | |
| location | No | Location name in Korean (e.g., '강남', '강남역', '홍대') | |
| amenities | No | Required amenities (e.g., ['wifi', 'parking']) | |
| bathrooms | No | Minimum bathrooms required | |
| mood_tags | No | Mood tags (e.g., ['luxury', 'cozy']) | |
| max_guests | No | Minimum guest capacity required | |
| view_types | No | View types (e.g., ['river', 'city', 'mountain']) | |
| pet_allowed | No | Pet-friendly rentals only | |
| kid_friendly | No | Kid-friendly rentals only | |
| property_type | No | Property type (e.g., '아파트', '펜트하우스', '주택') | |
| is_private_entire | No | Entire private space (not shared) | |
| max_price_per_week | No | Maximum price per week in KRW | |
| min_price_per_week | No | Minimum price per week in KRW |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the filtering is SQL-based without semantic ranking, returns Schema.org format, and sorting behavior. Lacks details on pagination or empty results, but sufficient for a search 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?
Three sentences, front-loaded with critical usage condition, no redundancy. Every sentence contributes essential 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?
With 15 parameters and no output schema or annotations, the description effectively fills gaps by explaining tool function, return format, sorting, and sibling distinction. Lacks mention of error handling, but schema covers limits.
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 each parameter described. The description adds no additional parameter meaning beyond what the schema provides, so baseline score of 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?
Clearly states the tool filters rentals using explicit numeric/categorical constraints and returns sorted results. Explicitly distinguishes from sibling search_rentals_natural by contrasting usage 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?
Explicitly says 'Use ONLY when the query consists entirely of explicit numeric/categorical constraints with NO descriptive language', and directs to sibling tool for any query with descriptors. Provides clear when-to-use and when-not-to-use guidance.
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!