listing
Server Details
List on MLS, sell, show, compare and close your real estate property on beycome.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 12 of 12 tools scored.
Each tool targets a distinct stage of the listing flow (discovery, account, create, payment, questionnaire, publish, post-publish) with no functional overlap. The descriptions clearly delineate the purpose and prerequisites for each tool.
All tools follow a consistent 'beycome_verb_noun' pattern (e.g., beycome_check_coverage, beycome_create_property, beycome_signin). The naming is predictable and well-structured, making it easy for an agent to infer the action and resource.
12 tools is well-scoped for a comprehensive MLS listing workflow. Each tool serves a clear and necessary function, covering discovery, account management, property creation, payment, questionnaire, publishing, and post-publish activities.
The tool set provides a complete end-to-end coverage for listing a property: coverage check, comps, estimate, sell timing, signup/signin, property creation, package selection/payment, MLS questionnaire, disclosures, publishing, and showings. No obvious gaps in the workflow.
Available Tools
12 toolsbeycome_check_coverageAInspect
Discovery stage — is this state served by beycome MLS? (GET /mls/is-covered).
No account or prop_id needed. Use before listing to confirm beycome operates
in the property's state; is_active: true means covered. If not covered,
the listing flow does not apply.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | State short code (e.g. FL) or full name (e.g. Florida). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses it's a GET request, requires no account or prop_id, and describes the response indicator. Does not mention read-only nature explicitly or potential errors, but these are implied by the simple nature of the 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?
Description is two short paragraphs, front-loaded with purpose, endpoint, and usage context. Every sentence serves a purpose with 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 simple coverage check with one parameter and an output schema available, the description adequately covers the discovery stage, the check's meaning, and the next steps. It is complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context beyond the schema by noting that no account or prop_id is needed, and that the state parameter can be short code or full name. This adds 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 it's a 'discovery stage' tool to check if a state is served by beycome MLS. It mentions the HTTP endpoint and the meaning of the response ('is_active: true'). It distinguishes from siblings by indicating it's a pre-listing check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before listing to confirm beycome operates in the property's state' and explains the implication: if not covered, listing flow does not apply. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_compsAInspect
Discovery stage — sold comparable listings near a location (GET /comps).
No account or prop_id needed. Supports price / beds / baths / area / lot /
type filters. Use during discovery to support pricing alongside
beycome_estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | Number of result pages to fetch. | |
| beds_max | No | Maximum beds. | |
| beds_min | No | Minimum beds. | |
| location | Yes | Location string (city, state, ZIP, etc.). | |
| baths_max | No | Maximum baths. | |
| baths_min | No | Minimum baths. | |
| price_max | No | Maximum price. | |
| price_min | No | Minimum price. | |
| lot_size_max | No | Maximum lot size sqft. | |
| lot_size_min | No | Minimum lot size sqft. | |
| property_type | No | Comma-separated types (singlefamily, condo, townhouse, multifamily, manufactured, land, apartment). | |
| living_area_max | No | Maximum living area sqft. | |
| living_area_min | No | Minimum living area sqft. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It correctly indicates a safe read operation (GET, no account needed) and lists supported filters. However, it omits behavioral details such as pagination behavior (despite the `pages` parameter), result limits, data freshness, or any rate limiting.
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 very concise: two sentences plus a bullet-style list of filters. It front-loads the core purpose and follows with essential context. No superfluous text.
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 presence of an output schema and high schema coverage, the description adequately covers the tool's role (discovery, pricing support) and filter capabilities. It could be slightly more complete by addressing pagination or result size, but it is sufficient for an agent to use the tool correctly.
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 groups parameters into categories (price, beds, etc.) but does not add significant meaning beyond the parameter-level descriptions already present in the schema. The `pages` parameter is mentioned in the description but without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving sold comparable listings near a location during the discovery stage. It identifies the HTTP method (GET /comps) and distinguishes itself from the sibling `beycome_estimate` by noting it is used alongside for pricing support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use during discovery to support pricing, and explicitly states that no account or prop_id is needed. It implicitly differentiates from `beycome_estimate` but does not enumerate alternative tools or explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_create_propertyAInspect
Create stage — create the listing in one call (POST /properties/draft).
The first step after login. Requires the signed-in user's access_token
(from beycome_signin) so the listing is owned by them. The server geocodes
the address, creates the row, stamps ownership, and sets
approve_status='pending' (Incomplete) — all server-side; this tool is a pure
pass-through (pass address + access_token).
Returns the create response. Read the new property id at data.data.id
(the API returns it at data.id; this server's helper wraps the API
payload under its own data key). That prop_id is the key to every
later step: beycome_list (choose package + pay), beycome_mls_questionnaire,
and beycome_publish.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City. | |
| address | Yes | Full property address string; the server geocodes it. | |
| postal_code | No | Postal Code. | |
| street_name | No | Street Name. | |
| unit_number | No | Unit Number. | |
| access_token | Yes | Bearer access token from beycome_signin. | |
| parcel_number | No | Parcel Number (Tax number, APN, Folio). | |
| public_remarks | No | Public listing description / remarks. | |
| state_or_province | No | State Or Province. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully carries the burden. It discloses server-side actions (geocoding, ownership stamping, approve_status='pending'), the pass-through nature, and response structure (data.data.id). No contradictions; complete 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?
The description is concise and front-loaded with the purpose. Each sentence adds necessary information: one-liner purpose, then context, then response details. 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 complexity (9 parameters, output schema exists), the description covers all key aspects: purpose, prerequisites, side effects, response structure, and connection to sibling tools. It is complete for effective tool usage.
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 value by explaining the pass-through concept (only address and access_token are passed) and hinting that other parameters are optional. This provides insight beyond schema 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's purpose: 'Create stage — create the listing in one call (POST /properties/draft).' It identifies the main action (creating a property listing) and the resource (first step after login). It also implicitly distinguishes from siblings by noting it's the first step.
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 explicitly says 'The first step after login' and 'Requires the signed-in user's access_token (from beycome_signin).' It also lists sibling tools that use the resulting prop_id, providing clear when-to-use context. Not explicit about when not to use, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_disclosuresAInspect
Questionnaire stage — required MLS documents/disclosures (GET /mls/documents).
Companion to beycome_mls_questionnaire. Requires prop_id and
access_token. Lists the disclosures/documents the listing needs before it
can be published with beycome_publish.
| Name | Required | Description | Default |
|---|---|---|---|
| prop_id | Yes | Property id of the listing in beycome. | |
| access_token | Yes | Bearer access token from beycome_signin. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the burden is higher. Indicates it's a GET request and requires authentication. However, does not disclose idempotency, rate limits, or side effects. As a simple list operation, it's adequate but not exemplary.
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 with no fluff. Front-loaded with the main purpose, efficiently adding companion and prerequisite context.
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 params, list operation, output schema present), the description covers purpose, related tools, and prerequisites completely. No missing critical information.
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?
Both parameters are already fully described in the schema (100% coverage). The description only states they are required, adding no new semantic depth 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?
Clearly states the tool lists required MLS documents/disclosures for a property, using a specific verb 'Lists'. Distinguishes from sibling tools by mentioning it's a companion to 'beycome_mls_questionnaire' and a prerequisite for 'beycome_publish'.
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 context on when to use: as a companion to 'beycome_mls_questionnaire' and before publishing with 'beycome_publish'. Implies the sequence but does not explicitly exclude scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_estimateAInspect
Discovery stage — estimate a property's value (beycome CMA + Zillow Zestimate).
No account or prop_id needed. Returns both estimates plus suggested pricing
strategies (fast / balanced / max). Use during discovery to set a list price;
pair with beycome_comps. For a sell-now timing opinion, use
beycome_sell_timing.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | Optional unit number (for example 101 or #101). | |
| address | Yes | Full property address (street, city, state, zip when available). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that no account or prop_id needed, and mentions both estimates plus pricing strategies. Could add more about external API dependencies or error handling.
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 front-load the main purpose and add necessary context without 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?
Tool has simple parameters, output schema present, and description covers usage, return values, and alternatives, making it complete for the task.
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 schema documents both parameters adequately. Description does not add significant meaning beyond what is already in the schema for address and unit.
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?
States it estimates property value using beycome CMA and Zillow Zestimate, clearly indicating the tool's function and distinguishes from siblings by specifying discovery stage usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (discovery to set list price), suggests pairing with `beycome_comps`, and directs to `beycome_sell_timing` for alternate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_listAInspect
Choose-package + pay stage — start the paid listing (needs prop_id + token).
Step after beycome_create_property. Calls GET /mls/initial-load (loads the
listing's MLS data) then POST /payments/stripe-checkout (creates a Stripe
checkout for the chosen package/premium). Requires prop_id and
access_token; set pay_amount / pay_premium_opt for the selected
package. The property must be eligible — a bare draft returns "not eligible".
After payment, fill the questionnaire via beycome_mls_questionnaire.
Package catalog — the chosen references feed pay_premium_opt.
Base packages (choose exactly one):
146 — Basic — listed on your local MLS + syndicated (Zillow, Redfin, Realtor.com) — $99
145 — Basic + Title — $199
263 — Enhanced — Basic plus professional photos + drone — $399
291 — Concierge — full-service, everything included — $999
Add-ons (optional, any number):
233 — 25 Professional HD Photos — $189
30 — Beycome Spotlight (Featured) Listing — $29
236 — 3D Tour — $99
235 — Drone — $99
234 — Premium Title / Escrow ($99 settlement) — $99
286 — Home Warranty (Armadillo) — $19.99
262 — Full CMA report — $65
261 — Broker support (contract / legal) — $199
284 — Reset days-on-market to 0 — $79
35 — 1x Pro Yard Sign — $34.99
43 — 1x Keylock Box — $30
42 — Open House Signage Kit — $44.99
How to use: present these to the user, let them choose one base package plus
any add-ons, then join the chosen references with | into
pay_premium_opt (e.g. 146 alone, or 146|233|30 for Basic + photos
featured).
Don't double up: Enhanced (263) and Concierge (291) already include professional photos and drone — do not also add 233 / 235 / 236 to those tiers.
Note: these are standard prices; the final amount is confirmed on the checkout page the tool returns, and a few states (e.g. TX, NC) can differ.
| Name | Required | Description | Default |
|---|---|---|---|
| prop_id | Yes | Property id in beycome. | |
| cancel_url | No | URL to redirect to if checkout is cancelled. | |
| pay_amount | No | Payment amount for the listing checkout. | |
| access_token | Yes | Bearer access token from beycome_signin. | |
| pay_premium_opt | No | Premium option string (e.g. '2|233|30'); see the tool description for the package list. | |
| shipping_address | No | Shipping address for the order. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it calls two endpoints (GET /mls/initial-load and POST /payments/stripe-checkout), creates a Stripe checkout, and states that a bare draft returns 'not eligible'. It also notes price differences in some states and that final amount is confirmed on the checkout page, giving the agent full awareness of side effects.
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 long but well-structured: a brief summary, then instructions, then a detailed catalog. It is front-loaded with the main purpose. Every sentence serves a purpose, though the catalog could be summarized slightly. Still, it remains functional 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?
The description positions the tool within the workflow (after create_property, before questionnaire), covers prerequisites, eligibility, and special cases (state differences). An output schema exists, so the lack of return value explanation is acceptable. It is thorough for a complex 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?
Although schema coverage is 100% (baseline 3), the description adds significant value beyond schema by explaining the package catalog with IDs and prices, how to combine them into `pay_premium_opt`, and the meaning of `pay_amount` in context. This reduces cognitive load for 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 explicitly states the tool's purpose: 'Choose-package + pay stage — start the paid listing'. It clearly identifies the tool as the next step after `beycome_create_property` and distinguishes it from siblings by naming the subsequent step `beycome_mls_questionnaire`. The verb 'start' and resource 'paid listing' provide precise action and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Step after `beycome_create_property`' and requirements for `prop_id` and `access_token`. It details how to construct `pay_premium_opt` using the package catalog and warns against double-ups (e.g., not adding 233/235/236 to Enhanced or Concierge). This leaves no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_mls_questionnaireAInspect
Questionnaire stage — fetch the MLS questionnaire data (GET /mls/data-questionnaire).
Runs after package selection/payment (beycome_list). Requires prop_id
and access_token. Returns the data needed to complete the listing's MLS
questionnaire. Pair with beycome_disclosures for required documents, then
finalize with beycome_publish.
| Name | Required | Description | Default |
|---|---|---|---|
| prop_id | Yes | Property id of the listing in beycome. | |
| access_token | Yes | Bearer access token from beycome_signin. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates it's a GET request that returns data, but does not elaborate on side effects, rate limits, or permissions beyond requiring tokens. Adequate but not detailed.
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 concise with front-loaded purpose. Uses formatting for clarity. A minor omission: the backtick usage could be slightly streamlined, but overall efficient.
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 an output schema present, return values need not be detailed. The description explains the tool's role in the pipeline and required inputs. Fits the context well for a simple data retrieval 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% with descriptions for both parameters. The description reiterates their necessity but adds no new semantics 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?
Clearly states it fetches MLS questionnaire data and positions it as a stage after package selection/payment, distinguishing it from siblings like beycome_disclosures and beycome_publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to run (after beycome_list) and how to combine with beycome_disclosures before finalizing with beycome_publish. Lacks explicit exclusions but provides clear sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_publishAInspect
Confirm stage — confirm the questionnaire and publish to MLS (POST /mls/confirm-questionnaire).
Final step of the listing flow. Requires prop_id and access_token.
Confirms the completed questionnaire and pushes the listing live to MLS — run
only after beycome_list (paid) and beycome_mls_questionnaire are done.
| Name | Required | Description | Default |
|---|---|---|---|
| prop_id | Yes | Property id of the listing in beycome. | |
| access_token | Yes | Bearer access token from beycome_signin. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'pushes the listing live to MLS' implying finality, but doesn't explicitly mention irreversibility or consequences of incomplete questionnaire.
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?
Extremely concise: two sentences plus a one-line summary. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, dependencies, and required parameters. Has output schema (not shown) so return values are covered. Missing mention of error conditions (e.g., incomplete questionnaire), but overall adequate for a final step 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% and already describes both parameters. Description only restates that they are required, adding no additional semantic 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?
Clearly states it confirms the questionnaire and publishes to MLS. Distinguishes from siblings by positioning as the final step after beycome_list and beycome_mls_questionnaire.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it requires prop_id and access_token, and that it should only be run after beycome_list and beycome_mls_questionnaire are done, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_sell_timingAInspect
Discovery stage — should the owner sell now? Offline heuristic, no account or API call.
First-touch tool in the journey, before any account exists. Weighs market
trend, seller urgency, and whether the target price is reachable, returning a
verdict (yes, likely_yes, probably_wait, it_depends) with a short
reason. Needs no prop_id or access_token. Pair with beycome_estimate and
beycome_comps for real numbers; when the owner decides to list, move on to
beycome_signup / beycome_signin.
| Name | Required | Description | Default |
|---|---|---|---|
| market_trend | No | Current local market condition: "hot", "neutral", or "cool". | neutral |
| urgency_days | No | How soon, in days, the owner needs or wants to sell. | |
| target_price_reached | No | True if the owner's desired sale price is already achievable. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is an offline heuristic making no account or API calls, and outputs a verdict with reason. This sufficiently conveys the behavior, though it could mention if there are any side effects or rate limits; however, being offline makes those unlikely.
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?
Extremely concise: only three sentences. Front-loaded with the main purpose and key differentiator. Every sentence adds value and there is no redundancy. Ideal structure.
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 (3 optional params, output is a verdict and reason), the description is nearly complete. It mentions the output format and pairing with siblings. The presence of an output schema (though not detailed here) further supports completeness. Lacks a slightly explicit list of sibling distinctions, but the context signals and sibling list cover that.
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 baseline is 3. The description reiterates that it weighs market trend, urgency, and target price, but does not add significant semantics beyond what the schema already provides for each parameter. It offers context for how they are used together, but the added value is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's purpose: deciding if the owner should sell now ('should the owner sell now?'), identifies it as a discovery stage tool, and distinguishes it from siblings by noting it's offline and requires no account. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines when to use ('First-touch tool in the journey, before any account exists') and when to move on ('when the owner decides to list, move on to beycome_signup / beycome_signin'). Also guides pairing with other tools for real numbers, providing clear context on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_showingsAInspect
Post-publish stage — calendar of showings, open houses, offer deadlines (GET /calendar/events).
Used once a listing is live. Requires access_token; optionally filter by
date range, prop_id, or event type (showing / open_house / offer).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by event type. | |
| prop_id | No | Filter events by property id. | |
| to_date | No | End date for the calendar range (YYYY-MM-DD). | |
| from_date | No | Start date for the calendar range (YYYY-MM-DD). | |
| access_token | Yes | Bearer access token from beycome_signin. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the required access_token and optional filters (date range, prop_id, type). However, it does not explicitly state that it is a read-only operation or describe the response format, though an output schema exists which may cover the latter.
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 core purpose, and contains no redundant information. Every phrase 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?
Given the tool's simplicity (read operation with optional filters) and the existence of an output schema, the description is almost complete. It could mention that it retrieves a list of events or that it's read-only, but the overall context is sufficient for an 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 description coverage is 100%, so baseline is 3. The description reiterates the optional filters but adds no new semantic meaning beyond the schema descriptions. It correctly notes the access_token requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for the 'Post-publish stage — calendar of showings, open houses, offer deadlines' and specifies the HTTP method and endpoint (GET /calendar/events). It distinguishes from sibling tools like beycome_publish and beycome_list by focusing on events after a listing is live.
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 explicitly says 'Used once a listing is live,' providing a clear context for when to use this tool. It does not mention when not to use it or suggest alternatives, but the sibling list and context signals help differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_signinAInspect
Account stage — sign in to get the access_token (POST /auth/login).
The gateway to the listing flow. The returned Bearer token (at
data.data.access_token) must be passed as access_token to every
authenticated tool: beycome_create_property, beycome_list,
beycome_mls_questionnaire, beycome_disclosures, beycome_publish, and
beycome_showings. Next step after login is beycome_create_property.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email address. | ||
| password | Yes | User password (min 6 characters). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output structure (access_token at data.data.access_token) and the necessity to pass it to other tools. However, it lacks details on error scenarios, session duration, or rate limits. Adequate but not comprehensive.
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 long, front-loads the purpose, and efficiently conveys the token usage and next step. There is no redundant or extraneous 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?
Given the tool's role as an authentication step, the description adequately covers purpose, token usage, and next step. An output schema is present, so no need to detail return values. It is complete enough for the intended use case, though could mention error responses.
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 provides 100% coverage of parameters (email and password) with clear descriptions. The tool description adds no additional meaning beyond what the schema already conveys, so the default moderate score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: sign in to get an access token via POST /auth/login. It distinguishes itself from sibling tools by being the sole authentication entry point and specifies the next step (beycome_create_property).
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 explicitly indicates when to use this tool (as the gateway to the listing flow) and lists all authenticated tools that require the token. It also provides a clear next step after login. While it does not explicitly state when not to use it, the context is sufficient for an authentication tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
beycome_signupAInspect
Account stage — register a new beycome user (POST /auth/register).
Use when the owner has no account yet. After registering, call
beycome_signin to obtain the access_token that every later step in the
listing flow requires. No prop_id needed.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email address. | ||
| phone | Yes | User phone number. | |
| is_owner | No | 1 if the user is a landlord/owner, 0 otherwise. | |
| lastname | No | User last name. | |
| firstname | Yes | User first name. | |
| company_name | No | Company name. | |
| sms_unsubscribe | No | SMS opt-in flag: 0 = opt-in, 1 = opt-out. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions registration is the first step and that signin is required next, but does not explicitly state that this is a write/mutate operation, nor does it cover potential side effects like email verification or duplicate user handling. For a signup tool, the transparency 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: first sets context, second gives usage guidance. No filler or redundant information. Every word earns its place.
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 that the tool has an output schema (not shown) and is a straightforward registration, the description covers purpose, usage, and next step. It omits details about error conditions (e.g., user already exists), but overall it is sufficient for an agent to understand and invoke the tool correctly in the listing flow.
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 input schema already documents all parameters. The description adds minimal extra meaning beyond noting that prop_id is not needed. Baseline score of 3 is appropriate since schema does the heavy lifting.
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 registers a new beycome user via POST /auth/register, and distinguishes it from siblings by noting the need to call beycome_signin afterwards. This is a specific verb+resource combination with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the owner has no account yet' and directs the user to call beycome_signin next. Also notes that no prop_id is needed, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!