A
licenseA
qualityC
maintenancePhilippine real estate data for AI agents — search verified listings, calculate transfer costs, and get accurate legal information via lupaph.com.
6
55
MIT
EPK Properties Public Knowledge MCP
Server Details
Public EPK real estate listings and multilingual guides for Panama and the Dominican Republic.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
6 toolsfetchFetch EPK public documentARead-onlyIdempotentInspect
Use this when the user wants the full public property or guide document identified by a stable public EPK document ID or a prior search result.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stable public EPK document ID supplied by the user or returned by search. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the document is public and full, which is mildly useful context, but provides no additional behavioral detail such as error behavior, availability, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that immediately states the usage condition, the resource type, and the identifier source. Every phrase contributes meaning and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-ID tool with one fully documented parameter, complete annotations, and an output schema present, the description covers what the tool does, when to use it, and what identifier to pass. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single 'id' parameter, including its source (user or search) and stability. The description essentially restates this provenance rather than adding new parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (fetch the full public property or guide document) and identifies the resource by a stable EPK document ID or prior search result. It is clear enough to distinguish from search tools, though it does not explicitly name sibling alternatives like get_guide_section or get_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this when the user wants the full public property or guide document' gives clear conditions for invocation. It does not explicitly mention when not to use it or which sibling alternatives to choose, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_guide_sectionGet public guide sectionARead-onlyIdempotentInspect
Use this when the user supplies a public EPK guide section ID or wants the complete section identified by search_guides.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stable public guide section ID supplied by the user or returned by search_guides. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| kind | Yes | |
| text | Yes | |
| title | Yes | |
| country | Yes | |
| section | Yes | |
| sources | Yes | |
| summary | Yes | |
| language | Yes | |
| metadata | No | |
| image_url | Yes | |
| countryName | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds that the resource is public (no auth implied) and that the tool returns the complete section as opposed to a summary or snippet. This is useful context beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence that front-loads the usage condition and the source of the ID. Every clause earns its place; there is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only retrieval tool with a complete input schema, explicit annotations, and an output schema present, the description provides sufficient context: when to call it, what it returns, and where the ID comes from. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter fully (pattern, type, description) at 100% coverage, so the baseline is 3. The tool description reiterates that the ID is public and comes from the user or search_guides but does not add meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get public guide section' names the verb and resource, and the description clarifies that it returns 'the complete section' for a given ID. It also distinguishes itself from search_guides by framing the ID as something search_guides returns, so an agent can tell it apart from the search sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly opens with 'Use this when the user supplies a public EPK guide section ID or wants the complete section identified by search_guides,' providing a clear trigger condition. It does not enumerate when-not-to-use or other alternatives, but the search_guides reference implies the division of labor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_propertyGet public propertyARead-onlyIdempotentInspect
Use this when the user supplies a public EPK property UUID or wants full public details for a result returned by search_properties.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | es | |
| property_id | Yes | Stable public property UUID supplied by the user or returned by search_properties. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-known. The description adds useful behavioral context by clarifying the input source (user-supplied UUID or output from search_properties) and indicates the tool returns full public details. It does not mention edge cases like invalid UUIDs or language default behavior, but it adds genuine value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, front-loading the trigger condition ('Use this when...') and the resource type. Every part earns its place, and it doesn't restate the field schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple read-only lookup with rich annotations (readOnly, idempotent, non-destructive) and a clear output schema exists, the description covers the key usage context: when to call it and what input to pass. Minor gaps such as the absence of the output format explanations are covered by the output schema, so overall the context is complete enough. A small deduction for not explicitly mentioning that the language parameter defaults to Spanish in the description, but this is in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: property_id has a description, but language's enum and default are structured only. The description adds context that property_id is a 'public EPK property UUID' supplied by the user or search_properties output, reinforcing the schema. Language parameter meaning is implicit but not problematic given the enum/default; the description doesn't repeat structured details and adds a bit of extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb with resource and context: 'get public property' when the user supplies a UUID or wants full public details for a search result. It also clearly distinguishes from sibling search_properties by saying this tool is for full public details for results returned by that search. The purpose is unambiguous and clearly related to the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user supplies a public EPK property UUID or wants full public details for a result returned by search_properties.' This provides concrete when-to-use guidance and implies the alternative (search_properties) is not the right tool when you already have a UUID. It is clear and actionable, even without an explicit when-not-to-use clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch EPK public knowledgeARead-onlyIdempotentInspect
Use this for EPK public knowledge searches and always when one request combines property listings with guides, regulations, taxes, residency, relocation, or due diligence. It returns both result types in one response and remains compatible with company knowledge and deep research.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| results | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context about the combined response type and compatibility with company knowledge/deep research, which goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every sentence serves a distinct function: usage guidance and behavior/benefit. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are rich, the description adequately covers usage, combined result behavior, and compatibility. For a simple one-parameter search tool, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the query parameter described as 'Natural-language search query'. The description does not add parameter-specific details, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Use this for EPK public knowledge searches' and specifies it returns 'both result types in one response', distinguishing it from siblings like search_guides and search_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: 'always when one request combines property listings with guides, regulations, taxes, residency, relocation, or due diligence' and implies alternatives for non-combined queries via the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_guidesSearch public real estate guidesARead-onlyIdempotentInspect
Use this when the user asks only for EPK public guidance about buying, taxation, regulations, residency, locations, rental management, relocation, or due diligence in Panama or the Dominican Republic. If the same request also asks for properties, use search instead so both kinds appear together.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Topic, regulation, tax, residency, location, or buying-process query. | |
| offset | No | ||
| country | No | ||
| language | No | Omit to infer the language from the query. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| results | Yes | |
| has_more | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety traits. The description adds behavioral context by specifying the content scope (guides only, not properties) and that using 'search' merges both kinds, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and alternative usage. Every word earns its place; it is concise and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation. The description covers use cases, distinctions, and topical scope. It is slightly incomplete in not mentioning language handling, but that is already covered in the schema. Overall, it is well-rounded for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 40%, so the description must compensate. It does so by enumerating query topics (buying, taxation, regulations, etc.) and geographic scope (Panama/Dominican Republic), giving meaning to the 'query' and 'country' parameters. It doesn't elaborate on limit/offset, but those are self-evident, and the schema provides defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool searches for public real estate guides on specific topics in Panama or the Dominican Republic. It uses a clear verb+resource combination and distinguishes itself from the sibling tool 'search' by clarifying that properties are excluded unless requested together.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this when the user asks only for EPK public guidance...' and an alternative: 'If the same request also asks for properties, use search instead'. This clearly delineates the boundary between search_guides and search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_propertiesSearch public propertiesARead-onlyIdempotentInspect
Use this when the user wants only public EPK Properties listings with explicit country, sale/rent, property type, price, bedroom, bathroom, area, location, or descriptive-keyword filters. SALE and RENT searches also include SALE_AND_RENT listings because they are available for the requested operation. If the same request also asks for guides or regulations, use search instead so both kinds appear together.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Location, property name, address, or keywords matched against public listing text. | |
| offset | No | ||
| country | No | PTY for Panama or DOM for the Dominican Republic. | |
| language | No | Language for descriptions and canonical listing URLs. | es |
| max_area | No | Maximum area in square metres. | |
| min_area | No | Minimum area in square metres. | |
| max_price | No | ||
| min_price | No | ||
| max_bedrooms | No | Maximum bedrooms; set equal to min_bedrooms for an exact bedroom count. | |
| min_bedrooms | No | Minimum number of bedrooms. | |
| max_bathrooms | No | Maximum bathrooms; set equal to min_bathrooms for an exact bathroom count. | |
| min_bathrooms | No | Minimum number of bathrooms. | |
| property_type | No | ||
| operation_type | No | Search by availability: SALE includes SALE and SALE_AND_RENT listings; RENT includes RENT and SALE_AND_RENT listings. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| results | Yes | |
| has_more | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is to add context beyond that. It adds the public-only scope constraint (not present in the schema) and the non-obvious SALE_AND_RENT inclusion behavior. That behavior is partially redundant with the operation_type parameter description, but the description still adds genuine value over the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the core purpose front-loaded; each sentence serves a distinct function: scoping the tool, disclosing inclusion behavior, and routing to the sibling. The SALE_AND_RENT sentence is slightly redundant with the operation_type schema description, which keeps this from a 5, but there is no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, annotations carry the safety profile, and the sibling set is large (five tools), the description covers the critical routing decisions (vs `search`), the scope boundary (public only), and a non-obvious result behavior. The main gap is that with 0 required parameters, the description never states what happens when no filters are supplied, and it doesn't clarify pagination behavior — minor gaps for a read-only, output-schema-backed search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, below the high-coverage baseline, so the description should compensate. It names the filter dimensions (price, property type, area, bedrooms, bathrooms) which loosely maps to the undocumented params (min_price, max_price, property_type), providing some compensation. However, it doesn't add detailed semantics beyond what the schema's own parameter descriptions already state, and pagination params (limit, offset) are not mentioned anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Use this when the user wants only public EPK Properties listings') naming both the verb and the exact resource scope, then enumerates the filter dimensions (country, sale/rent, property type, price, bedroom, bathroom, area, location, keywords). It differentiates from the sibling `search` tool directly in the final sentence, so an agent can distinguish them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit when-to-use condition ('when the user wants only public EPK Properties listings with explicit... filters') and an explicit when-not-to-use with a named alternative ('If the same request also asks for guides or regulations, use search instead'). The SALE_AND_RENT inclusion note also prevents a class of incorrect calls where an agent assumes SALE returns only SALE listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
- Changed
fetch1 field changed- changed
Input schema / properties / id / descriptionPrevious value: -"Document ID returned by search."New value: +"Stable public EPK document ID supplied by the user or returned by search."
- Changed
get_guide_section1 field changed- changed
Input schema / properties / id / descriptionPrevious value: -"Guide section ID returned by search_guides."New value: +"Stable public guide section ID supplied by the user or returned by search_guides."
- Changed
get_property1 field changed- changed
Input schema / properties / property_id / descriptionPrevious value: -"Public property UUID returned by search_properties."New value: +"Stable public property UUID supplied by the user or returned by search_properties."
- Changed
search_properties4 fields changed- changed
Input schema / properties / operation_type / descriptionPrevious value: -"Search properties for sale or rent."New value: +"Search by availability: SALE includes SALE and SALE_AND_RENT listings; RENT includes RENT and SALE_AND_RENT listings." - changed
Input schema / properties / query / descriptionPrevious value: -"Location, property name, address, or descriptive keywords."New value: +"Location, property name, address, or keywords matched against public listing text." - added
Output schema / properties / results / items / properties / operation_type / descriptionAdded value: +"Published availability; SALE_AND_RENT satisfies either a sale or rent search." - added
Output schema / properties / results / items / properties / operation_type / enumAdded value: +[ + "SALE", + "RENT", + "SALE_AND_RENT" +]
1 tool update
- Changed
search_properties4 fields changed- added
Input schema / properties / max_bathroomsAdded value: +{ + "description": "Maximum bathrooms; set equal to min_bathrooms for an exact bathroom count.", + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / max_bedroomsAdded value: +{ + "description": "Maximum bedrooms; set equal to min_bedrooms for an exact bedroom count.", + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / min_bathrooms / descriptionAdded value: +"Minimum number of bathrooms." - added
Input schema / properties / min_bedrooms / descriptionAdded value: +"Minimum number of bedrooms."
3 tool updates
- Changed
fetch8 fields changed- removed
Output schema / properties / countryRemoved value: -{ - "enum": [ - "PTY", - "DOM" - ], - "type": "string" -} - removed
Output schema / properties / countryNameRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / kindRemoved value: -{ - "const": "guide", - "type": "string" -} - removed
Output schema / properties / languageRemoved value: -{ - "enum": [ - "es", - "en", - "it" - ], - "type": "string" -} - removed
Output schema / properties / metadataRemoved value: -{ - "additionalProperties": {}, - "type": "object" -} - removed
Output schema / properties / sectionRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / sourcesRemoved value: -{ - "items": { - "additionalProperties": false, - "properties": { - "label": { - "type": "string" - }, - "url": { - "format": "uri", - "type": "string" - } - }, - "required": [ - "label", - "url" - ], - "type": "object" - }, - "type": "array" -} - removed
Output schema / properties / summaryRemoved value: -{ - "type": "string" -}
- Changed
get_guide_section2 fields changed- added
Output schema / properties / image_urlAdded value: +{ + "format": "uri", + "type": "string" +} - changed
Output schema / requiredPrevious value: -[ - "id", - "title", - "url", - "text", - "kind", - "country", - "countryName", - "language", - "section", - "summary", - "sources" -]New value: +[ + "id", + "title", + "url", + "text", + "kind", + "country", + "countryName", + "image_url", + "language", + "section", + "summary", + "sources" +]
- Changed
search_guides2 fields changed- added
Output schema / properties / results / items / properties / image_urlAdded value: +{ + "format": "uri", + "type": "string" +} - changed
Output schema / properties / results / items / requiredPrevious value: -[ - "id", - "title", - "url", - "text", - "kind", - "country", - "countryName", - "language", - "section", - "summary", - "sources" -]New value: +[ + "id", + "title", + "url", + "text", + "kind", + "country", + "countryName", + "image_url", + "language", + "section", + "summary", + "sources" +]
6 tool updates
- First observed
fetch - First observed
get_guide_section - First observed
get_property - First observed
search - First observed
search_guides - First observed
search_properties
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
Puerto Rico & Colombia real estate: listings, sales, parcels, permits, analytics, AVM reports.
Free public real estate listing exchange. Search, retrieve, and submit inquiries on listings.
First-party Spanish, Portuguese and Italian property listings with notarial-verified prices.
Real events, reviewed places, and ticket checkout across the Caribbean and Latin America.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceRemote Model Context Protocol server for finding authorized real-estate listings in Mexico. It provides public property search, details and contact options, plus OAuth-protected favorites and publishing tools.MIT
Evlek — Northern Cyprusofficial
AlicenseAqualityBmaintenanceAI-native property MCP for Northern Cyprus (KKTC). Search live listings, get the price index, compare cities and districts, estimate rental yield, and look up KKTC title-deed (koçan) procedures — all sourced live from evlek.app.18MIT- AlicenseAqualityAmaintenanceSearch vacation rental properties, check real-time availability, get canonical pricing quotes, and create direct bookings. Each property is its own node with live data. Supports staircase pricing, seasonal rates, and 11 languages.4131272Apache 2.0
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.3/5.0
Disambiguation4/5
The search tools are clearly separated by scope (combined vs guides-only vs properties-only), and the getters are typed by resource. However, `fetch` overlaps conceptually with `get_property` and `get_guide_section` because it also retrieves full property or guide documents, relying on a different ID type to distinguish itself.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern: search/search_guides/search_properties and get_guide_section/get_property. The single bare `fetch` breaks the pattern and uses a synonym for `get`, creating a minor but noticeable inconsistency.
Tool Count5/5
Six tools is a tight, well-scoped set for a public knowledge server covering properties and guides. Each tool serves a distinct query or retrieval need, and none feel redundant or out of place.
Completeness5/5
The set covers combined and filtered searching plus retrieval for property details, guide sections, and full public documents. For a read-only public knowledge domain, this is a complete lifecycle with no obvious dead ends.