U.S. real-estate data: property records, AVM value + rent estimates, sale/rental listings.
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 4.4/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: avm_rent and avm_value target rent vs. property value, while search_properties, search_rental_listings, and search_sale_listings each address different record types (property records, rental listings, sale listings). get_property is the only single-record retrieval tool. No overlap or ambiguity exists.
All tool names follow a consistent snake_case verb_noun pattern: avm_rent/avm_value, search_properties/search_rental_listings/search_sale_listings, and get_property. The naming is predictable and uniformly formatted with action prefixes and clear resource targets.
With 6 tools, the set is well-scoped for a real estate data server, covering property search, property detail, valuation models, and both rental and sale listings. Each tool earns its place without redundancy or excessive granularity.
The tool surface comprehensively covers the domain: property search with detailed records, single-property lookup, AVM for both rent and sale value, and listing search for both rental and sale. The read-only nature of the API means no CRUD operations are expected, and no obvious gaps remain for core workflows.
avm_rentAVM long-term-rent estimate with comparablesARun RentCast's automated model for long-term (12-month lease) rent and return a point rent estimate, a rentRangeLow/rentRangeHigh band, the resolved subjectProperty, and comparables[] — recent comparable rentals each scored with distance and correlation. Same subject-pinning rules as avm_value (address or latitude+longitude, plus optional subject attributes). Cached 6h upstream.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Subject property address. Required unless latitude+longitude are given. e.g. "5500 Grand Lake Dr, San Antonio, TX, 78244". | |
| daysOld | No | Max days since comparable rentals were last seen (min 1). | |
| bedrooms | No | Subject bedroom count; 0 indicates a studio. | |
| latitude | No | Subject latitude; alternative to address (requires longitude). | |
| bathrooms | No | Subject bathroom count; supports fractions. | |
| compCount | No | Number of comparable rentals to use in the estimate. Default 15. | |
| longitude | No | Subject longitude; alternative to address (requires latitude). | |
| maxRadius | No | Max distance between comparables and subject, in miles. | |
| propertyType | No | Subject property type; improves comparable selection. | |
| squareFootage | No | Subject living-area square footage. | |
| lookupSubjectAttributes | No | When true, RentCast looks up any missing subject attributes from its records. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable context beyond these: it specifies the output schema (point estimate, band, subject property, comparables), notes that comparables are scored by distance and correlation, mentions 'Cached 6h upstream', and references deterministic subject-pinning rules. No contradictions with annotations.
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 compact and front-loaded: the first sentence states the primary purpose and outputs, the second clarifies subject pinning, and the third notes caching. Every sentence contributes essential context without excessive detail. It is well-structured and avoids redundancy with the schema.
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?
Despite having 11 parameters and no output schema, the description provides a useful summary of return values (point estimate, range band, subjectProperty, comparables with scores) and mentions key behavior like caching and subject-pinning rules. It does not repeat parameter details already covered by the schema. A minor gap is not explicitly mentioning default behaviors like compCount default, but those are documented in the schema, so overall completeness is strong.
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 baseline is 3. The description does not add parameter-level semantics beyond what the schema already provides; it only restates that address or latitude+longitude can be used and that subject attributes are optional. No additional param details or examples are given in the description, so it neither compensates nor detracts from the schema's coverage.
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 function: 'Run RentCast's automated model for long-term (12-month lease) rent' and enumerates the specific outputs (point estimate, rentRangeLow/rentRangeHigh, subjectProperty, comparables). This distinguishes it from sibling avm_value (which is likely a sale value estimate) and other search tools by focusing on a long-term rent AVM with comparables.
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 calling it 'long-term rent estimate' and referencing 'Same subject-pinning rules as avm_value', indicating it is the rent counterpart to avm_value. It also clarifies the need for address or latitude+longitude and optional attributes. However, it does not explicitly state when to prefer this over alternatives like search_rental_listings, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
avm_valueAVM sale-value estimate with comparablesARun RentCast's automated valuation model for a subject property and return a point price estimate, a priceRangeLow/priceRangeHigh band, the resolved subjectProperty, and comparables[] — recent comparable sales each scored with a distance (miles) and correlation (0-1 similarity). Pin the subject with either address or latitude+longitude; when subject attributes are unknown, supply propertyType/bedrooms/bathrooms/squareFootage (or leave lookupSubjectAttributes true to have RentCast fill them). Cached 6h upstream.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Subject property address. Required unless latitude+longitude are given. e.g. "5500 Grand Lake Dr, San Antonio, TX, 78244". | |
| daysOld | No | Max days since comparable listings were last seen (min 1). | |
| bedrooms | No | Subject bedroom count; 0 indicates a studio. | |
| latitude | No | Subject latitude; alternative to address (requires longitude). | |
| bathrooms | No | Subject bathroom count; supports fractions. | |
| compCount | No | Number of comparables to use in the estimate. Default 15. | |
| longitude | No | Subject longitude; alternative to address (requires latitude). | |
| maxRadius | No | Max distance between comparables and subject, in miles. | |
| propertyType | No | Subject property type; improves comparable selection. | |
| squareFootage | No | Subject living-area square footage. | |
| lookupSubjectAttributes | No | When true, RentCast looks up any missing subject attributes from its records. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only/idempotent, and the description adds valuable behavioral context: the 'Cached 6h upstream' note explains freshness, and it discloses that RentCast may fill unknown subject attributes. This goes beyond what annotations provide.
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 packs a lot of information into three sentences: what it does, what it returns, how to specify inputs, and caching behavior. Every sentence earns its place without fluff.
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, the description compensates by listing the expected return fields (estimate, band, subjectProperty, comparables with distance and correlation). It covers the main input decision points and notes caching, making it complete for an AVM tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the address/lat-long alternative and the relationship between supplying subject attributes and enabling lookupSubjectAttributes, which helps the agent choose parameters correctly.
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 runs RentCast's AVM for a subject property and returns a point estimate, price range, resolved subject property, and scored comparables. It explicitly distinguishes this from its sibling 'avm_rent' by specifying 'sale-value estimate.'
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?
It provides concrete instructions on how to specify the subject (address or lat/long) and what to do when subject attributes are unknown, including the option to set lookupSubjectAttributes to true. It doesn't explicitly name alternatives like avm_rent, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_propertyGet one property record by idAFull detail for a single property record, keyed by its RentCast id (the same id returned on every search_properties, avm_value, avm_rent, and listings record). Returns 404 if no property matches the id. Cached 24h upstream.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | RentCast property id (from a prior search_properties, avm_value/avm_rent, or listings response), e.g. "5500-Grand-Lake-Dr,-San-Antonio,-TX-78244". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds two valuable behaviors: returns 404 on no match and has 24h upstream caching. These give context beyond the annotations without contradiction.
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 concise sentences, each adds new information, no redundancy, and the main purpose is front-loaded in the first sentence.
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 single-parameter retrieval tool, the description covers the purpose, id source, a specific error response, and caching. No output schema is present, but "full detail" is implicit; a bit more about the response content would be helpful, yet the description is adequate for the simplicity of the 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 for the single parameter is 100%, so the schema already documents the parameter fully. The description adds value by explaining the id is the RentCast id from prior endpoints, reinforcing the semantic source and context of the parameter.
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 fetches full detail for a single property record by RentCast id, which differentiates it from sibling search/AVM tools that return lists or values. The phrasing "single property record" and "keyed by its RentCast id" immediately convey the specific verb and resource.
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?
It explains that the id is the same as returned on every search_properties, avm_value, avm_rent, and listings record, implying usage after those calls. It also implies using this tool when full detail is needed. However, it does not explicitly state when NOT to use it or name direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_propertiesSearch property recordsASearch normalized U.S. property records (owner, structural attributes, tax assessments, tax + sale history) by location. Pin a location one of three ways: a full address, a city+state(+zipCode), or a latitude+longitude point with a radius (miles). All other parameters narrow the result set. Records are cached 24h upstream, so meta.cached may be true on repeat queries.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name; combine with state (and optionally zipCode) for an area search. | |
| limit | No | Max records to return per page. Default 50. | |
| state | No | 2-character state abbreviation, e.g. TX. | |
| offset | No | Number of records to skip, for pagination. Default 0. | |
| radius | No | Search radius in miles (max 100); used with latitude/longitude. | |
| address | No | Full address, format "Street, City, State, Zip". Alternative to city/state/zipCode or lat+long. e.g. "5500 Grand Lake Dr, San Antonio, TX, 78244". | |
| lotSize | No | Lot size in square feet; supports ranges and multiple values. | |
| zipCode | No | 5-digit ZIP code. | |
| bedrooms | No | Bedroom count; supports ranges and multiple values. | |
| latitude | No | Latitude of the search center; requires longitude and radius. | |
| bathrooms | No | Bathroom count; supports fractions, ranges, and multiple values. | |
| longitude | No | Longitude of the search center; requires latitude and radius. | |
| yearBuilt | No | Year built; supports ranges and multiple values. | |
| propertyType | No | Filter by property type. | |
| saleDateRange | No | Days since last sale (min 1) — restricts to properties last sold within that window. | |
| squareFootage | No | Living-area square footage; supports ranges and multiple values. | |
| includeTotalCount | No | When true, RentCast also returns the total matching count. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds value beyond annotations by revealing a 24h upstream cache and the behavior that meta.cached may appear on repeat queries. It does not describe response structure or error behavior, but the annotations lower the burden and the caching note is useful.
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 three sentences with no filler. It front-loads the core purpose, then explains input modes, and ends with a cache warning—every sentence earns its place. This is a model of concise, structured writing.
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 17 parameters and no output schema, the description covers the essential high-level behavior: data scope, location modes, filtering, and caching. It does not mention pagination or sort order, but the schema documents limit/offset and the first sentence hints at the return fields. Overall, it is sufficient for most use cases.
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 baseline is 3. The description adds meaningful parameter-relationship semantics by grouping the three location modes and stating that all other parameters narrow the result set, which helps agents avoid invalid combinations. This pushes it above the baseline.
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 this tool searches normalized U.S. property records with specific data categories (owner, structural, tax, sale history) and explains the three location-pinning modes. While it implicitly differentiates from listing/search siblings by focusing on property records, it does not explicitly name alternative tools, so it falls short of a 5.
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 gives clear usage context by explaining the three mutually exclusive location input methods and that all other parameters are filters. It does not mention when to choose this over sibling searches or any exclusions, so it lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_rental_listingsSearch active (or inactive) long-term rental listingsAReturn a page of long-term (12-month lease) rental listings — same record shape as search_sale_listings (monthly price is the asking rent), but each record is tagged listingKind:"rental-long-term". Same location-pinning rules and 30-minute upstream cache as the sale-listings endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name; combine with state for an area search. | |
| limit | No | Max listings to return per page. Default 50. | |
| price | No | Listed rent; supports ranges and multiple values. | |
| state | No | 2-character state abbreviation. | |
| offset | No | Number of listings to skip, for pagination. Default 0. | |
| radius | No | Search radius in miles (max 100); used with latitude/longitude. | |
| status | No | Listing status to return; defaults to Active. | |
| address | No | Full address to match a specific listing. | |
| daysOld | No | Max days since the listing was last seen (min 1). | |
| lotSize | No | Lot size in square feet; supports ranges and multiple values. | |
| zipCode | No | 5-digit ZIP code. | |
| bedrooms | No | Bedroom count; supports ranges and multiple values. | |
| latitude | No | Latitude of the search center; requires longitude and radius. | |
| bathrooms | No | Bathroom count; supports fractions, ranges, and multiple values. | |
| longitude | No | Longitude of the search center; requires latitude and radius. | |
| yearBuilt | No | Year built; supports ranges and multiple values. | |
| propertyType | No | Filter by property type. | |
| squareFootage | No | Living-area square footage; supports ranges and multiple values. | |
| includeTotalCount | No | When true, RentCast also returns the total matching count. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only, open-world, idempotent, and non-destructive. The description adds useful behavioral context: record shape mirrors search_sale_listings, each record is tagged listingKind:'rental-long-term', and upstream cache is 30 minutes. This goes beyond annotations and helps set expectations.
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 with the action, and every phrase adds value (lease term, shape, tag, cache). No fluff.
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 19 parameters and no output schema, the description references search_sale_listings for record shape, which provides a compact way to communicate return structure. It covers pagination ('page'), listing type, location rules, and cache behavior. It could be more self-contained without relying on sibling knowledge, but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 19 parameters, so the schema already provides full parameter semantics. The description adds no additional parameter meaning, just references the overall shape and cache, so a 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?
The description clearly states the tool returns rental listings with a specific lease term ('long-term (12-month lease)'), and distinguishes itself from the sibling search_sale_listings by noting the same record shape but with a listingKind tag and monthly price as rent.
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?
It gives context by referencing search_sale_listings and stating 'Same location-pinning rules and 30-minute upstream cache', implying this tool behaves like the sale-listings endpoint but for rentals. It does not explicitly exclude other tools but the rental/sale distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_sale_listingsSearch active (or inactive) sale listingsAReturn a page of for-sale listings (list price, status, days on market, MLS name/number, listing agent + office contact, and price/status history) for a location. Same location-pinning rules as search_properties (address, city+state(+zipCode), or latitude+longitude+radius). Each record is tagged listingKind:"sale". Listings move faster than records, so these are cached only 30 minutes upstream.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name; combine with state for an area search. | |
| limit | No | Max listings to return per page. Default 50. | |
| price | No | Listed price; supports ranges and multiple values. | |
| state | No | 2-character state abbreviation. | |
| offset | No | Number of listings to skip, for pagination. Default 0. | |
| radius | No | Search radius in miles (max 100); used with latitude/longitude. | |
| status | No | Listing status to return; defaults to Active. | |
| address | No | Full address to match a specific listing. | |
| daysOld | No | Max days since the listing was last seen (min 1). | |
| lotSize | No | Lot size in square feet; supports ranges and multiple values. | |
| zipCode | No | 5-digit ZIP code. | |
| bedrooms | No | Bedroom count; supports ranges and multiple values. | |
| latitude | No | Latitude of the search center; requires longitude and radius. | |
| bathrooms | No | Bathroom count; supports fractions, ranges, and multiple values. | |
| longitude | No | Longitude of the search center; requires latitude and radius. | |
| yearBuilt | No | Year built; supports ranges and multiple values. | |
| propertyType | No | Filter by property type. | |
| squareFootage | No | Living-area square footage; supports ranges and multiple values. | |
| includeTotalCount | No | When true, RentCast also returns the total matching count. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent/non-destructive annotations, the description discloses that listings are cached only 30 minutes upstream due to faster movement than records, and that each record is tagged with listingKind:"sale". This adds meaningful behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences; front-loaded with the main purpose and return fields. The reference to search_properties avoids repeating location rules, and the cache note is one brief sentence. 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?
For a 19-parameter search tool with no output schema, the description covers the core return fields, location constraints, record tagging, and caching behavior. It is sufficiently complete for an agent to understand what the tool does and how to invoke it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by explaining the valid location-pinning combinations (address, city+state(+zipCode), or latitude+longitude+radius), which is not obvious from inspecting each parameter individually. It does not repeat per-parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a page of for-sale listings with specific fields (list price, status, days on market, etc.). It explicitly tags records as listingKind:"sale" and references search_properties for location rules, distinguishing it from the rental listing sibling.
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 gives clear context: it is for for-sale listings and follows the same location-pinning rules as search_properties (address, city+state(+zipCode), or latitude/longitude/radius). It implies use for current sale listings versus rentals, but does not explicitly name alternatives or state when not to use it.
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!
Sign in to create a connector for this server.