Search curated community colivings and see who else will be staying during your dates.
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 3.7/5 across 14 of 14 tools scored.
Each tool has a clearly distinct purpose: search by different criteria, get details, check availability, list categories. The only potential overlap (checkAvailability vs checkAvailabilityBySlug) is differentiated by input type (ID vs slug), which is a reasonable distinction.
All tools follow a consistent camelCase pattern with lowercased verbs followed by nouns (e.g., checkAvailability, getColivingsByBudget). No mixing of conventions (e.g., snake_case, PascalCase) is present.
With 14 tools, the server covers the core operations for a coliving discovery platform: searching by multiple filters, viewing details, checking availability, and accessing metadata. The count feels well-scoped without being overwhelming or sparse.
The tool surface covers the main user journeys: discovering colivings via various criteria, getting detailed information, checking availability, and reading reviews. Minor gaps include the lack of combined filtering (e.g., country + budget) and no booking tool, but these are likely outside the intended read-only scope.
checkAvailabilityCheck Coliving AvailabilityAInspectCheck if a coliving has available accommodations for a specific date range and number of guests. Returns available room types with pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | No | Number of guests | |
| endDate | Yes | Check-out date in ISO 8601 format (YYYY-MM-DD) | |
| startDate | Yes | Check-in date in ISO 8601 format (YYYY-MM-DD) | |
| colivingId | Yes | The coliving ID to check availability for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns available room types with pricing, which is helpful, but lacks details on error handling, behavior when no availability, or any side effects. Given it's a read-only query, this is adequate but not outstanding.
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 main purpose, and contains zero wasted words. It is concise and to the point.
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 output schema, the description does a good job explaining the return value (room types with pricing). It covers the main input parameters. Could be improved by mentioning whether results are sorted or paginated, but overall complete for a simple query 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 parameters are well-described in the schema. The description reiterates the date range and guests but adds no new semantic information beyond what the schema already provides. 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 states the tool checks availability for a coliving given date range and guest count, and mentions it returns room types with pricing. It distinguishes from siblings like checkAvailabilityBySlug and getAvailabilityByMonth by specifying the parameters (colivingId, date range, guests) and output.
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 checking availability by coliving ID, date range, and guests, but does not explicitly state when to use this tool versus alternatives like checkAvailabilityBySlug, or provide exclusions (e.g., not for searching by slug).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
checkAvailabilityBySlugCheck Coliving Availability by SlugAInspectCheck if a coliving has available accommodations using its URL slug instead of ID. Returns available room types with pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The coliving URL slug (e.g., 'sun-and-co') | |
| guests | No | Number of guests | |
| endDate | Yes | Check-out date in ISO 8601 format (YYYY-MM-DD) | |
| startDate | Yes | Check-in date in ISO 8601 format (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it checks availability and returns data, implying a read-only operation, but does not disclose error handling, authentication needs, or rate limits. Adequate for a simple check but lacks depth.
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, zero waste. Every word earns its place. Front-loaded with action and resource.
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 output schema, the description explains return values ('available room types with pricing'). For a simple 4-parameter tool, this covers purpose, input, and output adequately. Missing error context, but sufficient for core functionality.
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 describes all parameters. The description adds no additional semantic meaning beyond the tool's purpose. 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 states the verb (check), resource (coliving availability), and distinguishes from siblings by specifying 'using its URL slug instead of ID'. It also mentions the return type (available room types with pricing).
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 when to use this tool versus the sibling 'checkAvailability' (when slug is available instead of ID). It provides clear context but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getAccommodationsGet Coliving AccommodationsAInspectGet all accommodation types (rooms, beds) for a specific coliving. Returns pricing, capacity, and unit details.
| Name | Required | Description | Default |
|---|---|---|---|
| colivingId | Yes | The coliving ID |
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 that it returns pricing, capacity, and unit details, but does not explicitly confirm that it is a read-only operation or disclose any potential side effects. This is adequate but not exceptional.
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 sentence with 15 words, front-loading the key action and resource. Every word earns its place with no unnecessary filler.
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 covers the main aspects: what it retrieves (accommodation types), for which entity (specific coliving), and what fields are returned (pricing, capacity, unit details). It could be improved by noting that it returns a list or array, but overall it is sufficient.
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 minimal description for colivingId. The description adds context that it is for a 'specific coliving' but does not provide additional meaning beyond the schema, such as data type or format constraints.
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 verb 'Get' and the resource 'all accommodation types for a specific coliving', and distinguishes itself from siblings like checkAvailability and getColivingById by focusing on accommodation types with pricing and capacity.
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 by requiring a colivingId, but does not explicitly state when to use this tool over alternatives or provide any exclusion criteria, such as when checkAvailability 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.
getAllCategoriesGet All CategoriesAInspectGet all available amenity and lifestyle categories that can be used to filter colivings. Categories are grouped into: location, food, coworking, facilities, structure, activities, community.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It indicates a read operation returning categories, but does not mention any constraints, rate limits, or data volume. The behavior is straightforward, lacking additional context.
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, front-loaded with the main action, and contains no fluff. Every word 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?
While the tool has no parameters and is simple, there is no output schema or description of the return structure. The description lists category groups but does not specify the format (e.g., array of strings or objects), which could help an agent interpret the response.
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 0 parameters, and schema coverage is 100% (empty schema). The description adds no parameter details beyond what the schema provides, but with no parameters, a baseline of 4 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 states 'Get all available amenity and lifestyle categories' with a specific verb and resource, and explains their purpose 'used to filter colivings', distinguishing it from sibling tools that filter colivings by those categories.
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 obtaining filter options, but does not explicitly say when to use this tool over alternatives like getColivingsByAmenities or getColivingsByLifestyle. No when-not or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getAllCountriesGet All Countries with ColivingsAInspectGet a list of all countries that have active colivings on Mapmelon, grouped by continent. Shows the number of colivings in each country.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output (grouped by continent, count) but does not disclose potential limitations like data freshness or pagination. Adequate for a simple read 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, no wasted words, clearly states what the tool does and what the output contains.
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 fully covers what the tool returns (list of countries with colivings, grouped by continent, with count). No gaps.
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?
No parameters present, baseline score 4 per guidelines. Description adds no parameter information, which is acceptable since none exist.
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 uses specific verb 'get list' and resource 'countries with active colivings', clearly distinguishing from siblings like getColivingsByCountry (filter by country) and getColivingsByContinent (filter by continent).
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?
No explicit when-to-use or when-not-to-use guidance. The purpose implies use for overview, but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getAvailabilityByMonthGet Monthly Availability CalendarAInspectGet a monthly availability overview for a coliving. Returns which accommodation types have available units for each week of the specified month.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Year (e.g., 2026) | |
| month | Yes | Month number (1-12) | |
| colivingId | Yes | The coliving ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the output (accommodation types with available units per week) but does not mention data freshness, error handling, or whether the response includes counts or just boolean availability. It is adequate but not thorough.
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 key purpose and add relevant detail. 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?
Given the simplicity (3 required params, no output schema), the description is fairly complete: it explains what the tool returns and the key parameters. However, it could be more explicit about the exact return structure (e.g., counts vs. boolean) and error conditions.
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% and descriptions are clear. The tool description adds minimal value beyond the schema, simply reinforcing that the tool uses colivingId, year, and month. No new parameter semantics are introduced.
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 verb 'get', the resource 'monthly availability overview', and the scope 'for a coliving' and 'for each week of the specified month'. It distinguishes from sibling tools like checkAvailability, which likely focus on specific dates.
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?
No explicit guidance on when to use this tool versus the many sibling tools (e.g., checkAvailability, getColivingsByCountry). The description implies use for monthly overviews but does not specify when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getColivingByIdGet Coliving DetailsAInspectGet full details for a specific coliving by its ID or URL slug. Returns comprehensive information including description, location, amenities, pricing, reviews, and accommodation types.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The coliving URL slug (e.g., 'sun-and-co', 'nine-coliving') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source for behavioral information. It discloses the return content comprehensively (description, location, amenities, pricing, reviews, accommodation types) but does not specify idempotency, read-only nature, or side effects. This is adequate but not exhaustive.
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-loaded with the purpose, and contains no unnecessary words. Every sentence adds value, 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 low complexity (one parameter, no output schema, no annotations), the description is fairly complete. It explains the input and output categories. However, it could benefit from mentioning that it returns data for a single coliving and not a list, which is implied but not explicit.
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 mentions both 'ID or URL slug' as input, but the schema defines only a 'slug' parameter. This creates ambiguity about whether ID is accepted, and the schema does not clarify the format for ID. Despite 100% schema description coverage, the tool description introduces confusion that may mislead the agent.
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 retrieves full details for a specific coliving using an ID or URL slug. It specifies the resource, action, and input mechanism, and is distinct from sibling tools that filter or list colivings by various 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 does not provide explicit guidance on when to use this tool versus alternatives. It lacks context on when not to use it or which sibling to prefer, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getColivingReviewsGet Coliving ReviewsAInspectGet user reviews for a specific coliving. Returns review text, ratings, and reviewer information.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The coliving URL slug | |
| limit | No | Maximum number of reviews to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It mentions return types (review text, ratings, reviewer info) but lacks disclosure of side effects, authentication needs, or rate limits. Adequate for a simple read operation but could be more 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?
Description is two sentences, front-loaded with purpose and concise. No unnecessary words or redundancy.
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 no output schema and simple parameters, the description covers the basics but lacks detail on the return object structure and any pagination behavior beyond the limit 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 100% with both parameters described. The tool description adds no extra meaning beyond the schema, providing only a high-level summary of return fields.
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 clearly states the tool retrieves user reviews for a specific coliving, using a specific verb 'Get' and resource. It distinguishes from sibling tools, as no other sibling tool is about reviews.
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?
Description implies usage for fetching reviews but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. No exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getColivingsByAmenitiesGet Colivings by AmenitiesAInspectSearch for coliving spaces that have specific amenities/categories. Use category names like 'pool', 'gym', 'surf', 'yoga', 'pet friendly', 'coworking', etc. Use getAllCategories tool to see all available categories.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| categories | Yes | List of category/amenity names to filter by (e.g., ['pool', 'gym', 'yoga']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as pagination, ordering, response format, or what happens if no results match. It only covers the basic filtering criteria.
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 states the purpose and the second provides usage guidance. It is front-loaded and contains no filler or 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?
There is no output schema, but the description does not explain return values or behavior (e.g., list of coliving objects, default limit, ordering). For a search tool, this leaves an information gap despite adequate parameter documentation.
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 fully describes both parameters (categories and limit). The description adds marginal value by providing example category names and directing to getAllCategories, but does not add significant new semantics beyond the schema’s own 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 the tool searches for coliving spaces by amenities, with specific verb 'Search for' and resource 'coliving spaces'. It provides example category names and directs to getAllCategories for full list, distinguishing from sibling tools that filter by budget, lifestyle, location, etc.
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 explains what to use for categories (names like 'pool', 'gym') and suggests using getAllCategories to see all options. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getColivingsByBudgetGet Colivings by BudgetAInspectSearch for coliving spaces within a price range. Prices are per night in EUR. Returns colivings with at least one accommodation within the specified budget.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| maxPrice | Yes | Maximum price per night in EUR | |
| minPrice | No | Minimum price per night in EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adds context about currency and budget condition but does not disclose whether the operation is idempotent, any authentication needs, rate limits, or behavior when no results match.
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: first states core action, second adds key details (currency and condition). No redundancy or unnecessary words. Perfectly front-loaded.
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 description should hint at return structure. It only says 'returns colivings with at least one accommodation', which is vague. Does not explain whether results are paginated, sort order, or what fields are returned. Adequate for a simple search but not fully 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?
Schema coverage is 100% with each parameter described. The description adds value by clarifying that 'Prices are per night in EUR', which enhances understanding of minPrice and maxPrice semantics. This goes beyond the schema's basic 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 the verb 'search', the resource 'coliving spaces', and the scope 'within a price range'. It specifies prices are per night in EUR and that results include colivings with at least one accommodation within budget. This effectively distinguishes from sibling tools that filter by other 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 implies usage when searching by budget but provides no explicit guidance on when to use versus alternatives like getColivingsByCountry or getColivingsByAmenities. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getColivingsByContinentGet Colivings by ContinentAInspectSearch for coliving spaces in a specific continent. Valid continents: Europe, Asia, Africa, North America, South America, Oceania.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| continent | Yes | Continent name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the search scope and valid continents but omits behavioral details like pagination, ordering, or what fields are returned. The behavioral disclosure is minimal.
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 with no fluff, front-loading the purpose clearly.
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 no output schema, no annotations, and only two simple parameters, the description is adequate but could be improved by mentioning the response structure or any limitations. It covers the basics but leaves gaps.
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 both parameters. The description adds the list of valid continents (also present in schema as enum) but does not provide additional 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 'Search for coliving spaces in a specific continent' and lists the six valid continents, providing a specific verb and resource that distinguishes it from siblings like getColivingsByCountry or getColivingsByBudget.
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 continent-based searches but does not explicitly state when to use this tool over alternatives (e.g., getColivingsByCountry) or when not to use it. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getColivingsByCountryGet Colivings by CountryAInspectSearch for coliving spaces in a specific country. Use ISO 3166-1 alpha-2 country codes (e.g., 'pt' for Portugal, 'es' for Spain, 'th' for Thailand).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| countryCode | Yes | ISO 3166-1 alpha-2 country code (e.g., 'pt', 'es', 'th') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not mention pagination, result format, or behavior when no results found. Only states input format.
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, front-loaded, no extraneous words. Efficient and clear.
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?
Adequate for a simple search tool but missing behavioral details like list return and limit parameter usage. Could be more 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?
Schema covers 100% of parameters with descriptions. Description adds example country codes but adds minimal value beyond 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?
Description clearly states 'Search for coliving spaces in a specific country' with specific verb and resource, and differentiates from siblings like getColivingsByContinent and getColivingsByBudget by focusing on country-level search.
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?
Provides format for country code but no explicit when-to-use or when-not-to-use guidance. Agents must infer from tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getColivingsByLifestyleGet Colivings by LifestyleAInspectSearch for coliving spaces by lifestyle category group. Groups: 'community' (shared meals, activities, min stay), 'location' (beach, city, mountain), 'coworking' (desks, monitors, call rooms), 'facilities' (pool, gym, kitchen), 'activities' (yoga, surf, hiking), 'food' (breakfast, vegan), 'structure' (apartments, dorms).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| lifestyle | Yes | Lifestyle category group name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether this is a read-only operation, any side effects, authentication needs, or rate limits. The description only lists category groups without behavioral 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 concise, fitting in a single sentence with a list. It front-loads the core purpose and then details the groups. No unnecessary words, though it could be slightly better structured with bullet points.
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 has only 2 parameters and no output schema, the description covers the main input. However, it does not describe the output format or any pagination behavior, which would be helpful for completeness.
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 meaning to the 'lifestyle' parameter by enumerating the enum values and providing subcategory examples. For 'limit', no additional info is added beyond the schema, but the overall coverage is good.
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 for coliving spaces by lifestyle category group. It lists the specific groups with examples, making the purpose distinct from sibling tools like getColivingsByAmenities or getColivingsByBudget.
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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives. It implies usage for lifestyle-based search, but lacks direct when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getColivingsByLocationGet Colivings by LocationAInspectSearch for coliving spaces by location name. Searches across city, region, country name, and coliving name. Use this for flexible location searches like 'Bali', 'Lisbon', 'Barcelona'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| query | Yes | Location search query (city, region, country, or coliving name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the multi-field search scope but omits key behavioral details such as result order, pagination, partial matching, and response format. For a search tool, this is insufficient transparency.
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 with no wasted words. The main action is front-loaded. Every sentence adds value. Ideal for quick scanning.
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 simplicity (2 parameters) and lack of output schema, the description is adequate but not thorough. It could provide more context on result behavior and differentiation from siblings to fully empower the agent.
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 baseline is 3. The description adds examples for the query parameter but essentially restates the schema description for 'query'. The 'limit' parameter is not elaborated beyond the schema. Thus, marginal added value.
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 'Search for coliving spaces by location name' and specifies the search covers city, region, country, and coliving name. While it distinguishes this tool as flexible, it does not explicitly contrast with more specific siblings like getColivingsByCountry, making it slightly less than perfect.
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 this for flexible location searches' and provides concrete examples ('Bali', 'Lisbon', 'Barcelona'). It implies suitable scenarios but does not explicitly state when not to use it or mention alternatives, leaving some ambiguity.
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!
