Search Florida properties and new construction for sale with U.S. Prime Realty.
Scored across 13 tools
Most tools map to clearly distinct actions (search, details, save, book/cancel/reschedule appointment, guides, CRM contact). The only real overlap is affordability_calculator vs mortgage_calculator, which both estimate costs and could be misselected without reading descriptions, but the descriptions do clarify (income-based estimate vs property price estimate).
The set mixes verb_noun patterns (book_appointment, search_properties, save_listings) with noun-first/resource-first names (affordability_calculator, mortgage_calculator, listing_details) and an awkward get_guides_list. Each name is readable on its own, but there is no single predictable convention an agent can rely on.
Thirteen tools is well within a healthy scope for a real estate lead-generation server. Each tool corresponds to a concrete user journey step (search, evaluate, save, book, capture lead, share guides) with no filler.
The surface covers search, listing detail, saving, financing calculators, guide sharing, appointment lifecycle (slots, book, reschedule, cancel), agent notification, and CRM capture — a full funnel. Minor gaps exist: no way to retrieve or manage previously saved listings, and no tool to fetch a single saved URL's contents.
Calculate an estimate of home affordability
| Name | Required | Description | Default |
|---|---|---|---|
| pmi | No | Private Mortgage Insurance (PMI) surcharge per month | |
| hoaDues | No | ||
| loanTerm | No | Loan term (months) | |
| calculateBy | No | income | |
| downPayment | No | ||
| propertyTax | No | Annual percentage | |
| annualIncome | No | ||
| debtToIncome | No | The debt to income ratio, as a percentage | |
| interestRate | No | ||
| monthlyDebts | No | ||
| homeInsurance | No | Annual amount | |
| maximumPayment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds only the word 'estimate' and does not explain assumptions, calculation modes, or what the estimate represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but for a 12-parameter calculator it is under-specified rather than appropriately concise. It is not front-loaded with any useful invocation 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 12 parameters, low schema description coverage, and no output schema, the description is far too sparse. It omits essential context such as calculation mode behavior, assumptions, and what the result estimate includes.
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 tool has 12 parameters with only 42% schema description coverage, and the description provides no parameter meaning at all. It does not explain calculateBy modes, units, defaults, or how income versus payment calculation changes the inputs.
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 states a clear verb and resource: calculate an estimate of home affordability. It does not distinguish this from the sibling mortgage_calculator, which is important because both are financial calculators.
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?
There is no guidance on when to use this tool versus mortgage_calculator or other sibling tools. The agent must infer the appropriate context entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book an appointment on the calendar
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | The contact ID returned in the `contact` field of a previous send_contact_info call in this conversation.Never guess, invent, or reuse an ID from elsewhere. If you don't have one yet, collect the person's name and email or phone and call send_contact_info first. | |
| startTime | Yes | The start time for the appointment (ISO 8601 format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-but-not-destructive profile is covered. The description adds nothing beyond that: it does not say what happens on a conflicting time slot, whether the booking is confirmed immediately, or what the caller should do if the contact does not exist yet.
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?
A single front-loaded sentence with no filler, so nothing is wasted, but it is under-specified rather than genuinely concise. The one line could easily have carried a slot-availability caveat without bloat.
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 mutation tool with no output schema and no annotations covering outcome semantics, the description should at least say whether a booking consumes a slot, fails on conflicts, or returns a confirmation. Given a 12-sibling surface, this is too thin to prepare an agent for correct invocation.
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% and the contactId property already contains strong procedural guidance about calling send_contact_info first and never inventing an ID. The description adds nothing to that, so the baseline 3 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 verb+resource pair ("Book an appointment") is specific enough to identify the action, but it stops there. It never distinguishes itself from sibling tools that operate on the same resource, notably cancel_appointment, reschedule_appointment, and get_appointment_slots, so an agent must infer which booking-adjacent tool applies.
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?
There is no statement of when to use this versus rescheduling, cancelling, or first checking slot availability via get_appointment_slots. Any prerequisite knowledge (that a contact must exist first) lives only in the parameter schema, not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel an existing appointment on the calendar
| Name | Required | Description | Default |
|---|---|---|---|
| bookingId | Yes | The booking ID returned by a previous book_appointment call in this conversation. Never guess or invent one; if you don't have it, ask the person to rebook or contact the brokerage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing about consequences: whether the slot is released, whether the brokerage/agent is notified, whether cancellation is reversible, or what a repeat call returns. For a destructive mutation, that is a real gap.
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?
A single front-loaded sentence with no padding or repetition. It is efficient, though the brevity reflects under-specification rather than tight 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?
A destructive, irreversible-sounding mutation with no output schema should tell the agent what state change occurs and what to expect afterward. Nothing here goes beyond the title, leaving the agent to infer the effects of a booking cancellation.
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 bookingId description is unusually rich, including the don't-invent warning and the fallback path. The description adds no parameter detail, so baseline 3 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?
States a specific verb (cancel) and resource (an existing appointment on the calendar), which is clear and actionable. It does not distinguish itself from the sibling reschedule_appointment, so it stops 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?
There is no guidance on when to use this versus reschedule_appointment, what preconditions exist (must the appointment exist in this conversation?), or what to do if the person actually wants to move rather than cancel the booking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific real estate guide's (or multiple guides') download link for the agent to share with the user
| Name | Required | Description | Default |
|---|---|---|---|
| guideIds | Yes | The IDs of the guides to download. Reference IDs from get_guides_list. | |
| contactId | Yes | The contact ID returned in the `contact` field of a previous send_contact_info call in this conversation.Never guess, invent, or reuse an ID from elsewhere. If you don't have one yet, collect the person's name and email or phone and call send_contact_info first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a safe, read-only, non-destructive operation. The description adds that it returns a download link intended for sharing, but it does not disclose link expiration, permissions, or other behavioral details beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no unnecessary filler. The parenthetical "(or multiple guides')" is slightly awkward but still clarifies scope efficiently.
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 read-only tool with full schema coverage and annotations covering safety, the description sufficiently states that it returns a shareable download link. It does not need an output schema, though it could mention link behavior or error 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%, and both parameters are fully documented in the schema with prerequisite and source instructions. The description adds no parameter-level meaning beyond noting that one or multiple guides can be requested, so the baseline 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 uses a specific verb ("Retrieve") and resource ("real estate guide's ... download link") and clarifies that it can handle one or multiple guides. It does not explicitly differentiate itself from the sibling get_guides_list tool, which is used to discover guide IDs.
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 phrase "for the agent to share with the user" implies the use case, but there is no explicit guidance on when to use this tool versus get_guides_list or other siblings. The schema provides prerequisite instructions, but the description itself offers only implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve available appointment slots from the calendar
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | The end time for the range of available slots to retrieve (ISO 8601 format) - max range is 2 weeks | |
| timezone | No | The timezone for the appointment slots (e.g.: America/New_York) | America/New_York |
| startTime | Yes | The start time for the appointment (ISO 8601 format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is fully covered. The description adds essentially nothing beyond that: it doesn't say whether returned slots are filtered by calendar, what a slot looks like, or that a 2-week max range applies (that lives only in the schema).
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?
A single short sentence with no wasted words, and the key action is front-loaded. It is arguably under-specified rather than over-long, so brevity here is a mild virtue, not a flaw.
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, well-annotated read tool with a fully documented 3-parameter schema and no output schema, the description is adequate but thin. It leaves the agent to infer the returned slot structure and the booking workflow context from sibling names rather than stating it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with date-time formats, the timezone default, and the 'max range is 2 weeks' constraint all documented in the schema itself. The description adds no parameter meaning on top, which is the correct baseline of 3 when the schema carries all the weight.
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 a specific verb+resource: 'Retrieve available appointment slots from the calendar'. It is clear what the tool does, though it does not differentiate itself from siblings like book_appointment, reschedule_appointment, or cancel_appointment, which any agent would need to choose among.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as book_appointment. The usage is only implied: an agent infers this is a pre-booking availability lookup, but nowhere does the description state that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a list of all available real estate guides for the agent to share with the user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the result is the complete set of guides intended for sharing, but says nothing about ordering, pagination, or what a guide entry contains.
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?
A single front-loaded sentence with no filler. It could be slightly sharper by naming the download sibling, but nothing is wasted.
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 zero-parameter, read-only list tool with annotations covering the safety profile and no output schema, the description gives enough to call it correctly. Only the relationship to download_guides is left implicit.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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?
States a specific verb ('Retrieve') and resource ('list of all available real estate guides'), so the agent knows exactly what it returns. It implicitly separates itself from download_guides by emphasizing a list rather than the files, but never names that sibling explicitly.
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 phrase 'for the agent to share with the user' implies the usage scenario, but there is no explicit guidance on when to call this versus download_guides (the obvious alternative) or any stated preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for either a single listing or several listings
| Name | Required | Description | Default |
|---|---|---|---|
| listings | Yes | An array of full listing IDs to retrieve details for (include at least 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no error behavior for unknown IDs, no note about required brokerage scoping, no rate or volume limits.
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?
One short, front-loaded sentence with no waste, but it is under-specified rather than genuinely concise — the brevity comes at the cost of routing information the agent needs.
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 read tool with no output schema and 11 siblings, the description should clarify what fields come back and how it relates to search_properties. The nested id+brokerage requirement is only in the schema, and no guidance on the single-vs-bulk tradeoff is given.
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% and the single 'listings' array parameter is well documented in the schema, so baseline 3 applies. The description's 'single or several' phrasing mildly reinforces the array semantics but adds no new detail about the required id/brokerage pair.
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 states a verb ('Get details') and resource ('listing'), and adds that it supports one or many listings. However, it largely restates the title and name, and does not distinguish the tool from search_properties or save_listings, which operate on the same 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?
There is no indication of when to use this tool versus search_properties (discovery) or save_listings (persistence). An agent must infer that this is a fetch-by-ID tool for listings it already knows about.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate an estimated mortgage price for a property
| Name | Required | Description | Default |
|---|---|---|---|
| rate | Yes | Annual interest rate (e.g., 7.5) | |
| price | Yes | Total listing price | |
| years | Yes | Loan term (years) | |
| downPayment | Yes | ||
| rentalIncome | No | Monthly rental income (dollars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — it doesn't say the result is an estimate, what assumptions are made (e.g., fixed-rate amortization), or how the optional rentalIncome parameter affects the output.
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?
A single short sentence with zero waste, but it is under-specified rather than well-structured — there is no front-loaded scope statement or qualifier to make the brevity productive.
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 five parameters, no output schema, and no explanation of return values, the description leaves a real gap: an agent cannot tell whether the result is a monthly payment, total interest, or a price estimate. For a calculator tool whose whole value is its output, this is a meaningful omission.
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 80%, so the schema itself documents price, rate, years, and rentalIncome. The description adds no meaning beyond those fields, and notably does not clarify that downPayment is the one undescribed parameter or that rentalIncome is optional.
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 a verb ("Calculate") and a resource ("mortgage price"), so the general intent is inferable. However, "mortgage price" is imprecise — the tool almost certainly returns an estimated payment, not a property price — and nothing distinguishes it from the sibling affordability_calculator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus affordability_calculator, which is the obvious overlapping sibling in the tool list. No prerequisites, no mention of what input scenarios it fits (e.g., monthly payment estimation for a specific listing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a request to notify an agent that the user requires attention
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Notes that should be saved along with the contact from the agent | |
| message | No | Additional message or notes from the user | |
| contactId | Yes | The contact ID returned in the `contact` field of a previous send_contact_info call in this conversation.Never guess, invent, or reuse an ID from elsewhere. If you don't have one yet, collect the person's name and email or phone and call send_contact_info first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-but-safe profile is covered. The description adds little beyond the name: it does not say whether this queues a request, pings a human immediately, is asynchronous, or what the caller should expect after the call.
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?
A single, front-loaded sentence with no filler. It is efficient, though the brevity edges into under-specification rather than crispness.
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 3-parameter escalation tool with no output schema, the definition is minimally adequate: annotations cover the safety profile and the schema covers the ordering dependency. What is missing is description-level disclosure of the workflow prerequisite and what the notification actually triggers.
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%, and the contactId description carries the full prerequisite and anti-hallucination guidance, so the schema does all the work. The description itself contributes no parameter meaning, which is the expected baseline when coverage is complete.
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 pairs a specific verb ('Send a request to notify') with a specific target ('an agent') and states the intent ('that the user requires attention'), which is far more informative than the bare name. It does not, however, distinguish this from the closely related sibling send_contact_info, which an agent might plausibly confuse it with.
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 phrase 'the user requires attention' implies a trigger condition (a live escalation need) but never states when to use this instead of alternatives, nor any exclusions. The critical prerequisite — that contactId must come from a prior send_contact_info call — appears only in the schema, not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reschedule an existing appointment on the calendar
| Name | Required | Description | Default |
|---|---|---|---|
| bookingId | Yes | The booking ID returned by a previous book_appointment call in this conversation. Never guess or invent one; if you don't have it, ask the person to rebook or contact the brokerage. | |
| startTime | Yes | The start time for the appointment (ISO 8601 format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the bar is lower, but the description adds no behavioral context at all. It does not say that the original slot is released or replaced, whether the old booking is cancelled, whether the caller must reconfirm, or what happens on conflict.
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?
A single clause with no filler, front-loaded with the verb and resource. It is efficient, though it spends its space restating the title rather than adding qualifying detail.
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 two-parameter mutation with full schema coverage and annotations carrying the safety profile, the essentials are covered by structured fields. Still, with no output schema, the description should say what a successful reschedule yields (a new or updated booking ID, confirmation) and whether the prior booking remains valid.
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%: bookingId carries strong guidance about sourcing the ID from a prior book_appointment call and never guessing it, and startTime is typed as an ISO 8601 date-time. The description adds nothing beyond that, so the baseline 3 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?
"Reschedule an existing appointment" names a specific verb and resource, and the word "reschedule" naturally distinguishes it from the sibling tools book_appointment and cancel_appointment. However, it does not explicitly name or route to those siblings, so the differentiation is inferred rather than stated.
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 phrase "existing appointment" implies a prerequisite (the booking must already exist), but the description states no when-to-use guidance, no when-not-to-use condition, and no explicit pointer to book_appointment for new bookings or cancel_appointment for cancellations. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save listings to a custom URL for the user, which should then be shared by the agent
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | The contact ID returned in the `contact` field of a previous send_contact_info call in this conversation.Never guess, invent, or reuse an ID from elsewhere. If you don't have one yet, collect the person's name and email or phone and call send_contact_info first. | |
| listingIds | Yes | Full list of Listing IDs to save to the user's profile, overwriting any previous saved listings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description never explains what is destroyed: per the schema, the full listing list overwrites prior saved listings. It does add one piece of context not present in annotations or any output schema, namely that the call yields a URL the agent must share, which is genuinely 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?
A single front-loaded sentence with no filler. The trailing clause about sharing is slightly awkwardly attached but still earns its place as the only statement of what to do with the result.
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 valuably discloses that the return is a shareable custom URL. However, for a destructive, non-idempotent-looking write with a required contactId prerequisite, it omits the overwrite consequence and the sequencing dependency, leaving those to the schema.
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%, including a strong warning about never guessing contactId, so the baseline is 3. The description adds no parameter-level meaning and does not reinforce the overwrite semantics of listingIds, leaving the schema to carry it entirely.
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 verb+resource ("Save listings") is clear, but the stated destination, "a custom URL," conflicts with the schema's "save to the user's profile, overwriting any previous saved listings." The description never distinguishes this from siblings such as listing_details or search_properties, so an agent must infer when this write path is the right one.
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?
There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The only guidance is the vague instruction that the result "should then be shared by the agent," which describes a post-step rather than a selection criterion. The prerequisite (a contactId from send_contact_info) is documented only in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Florida listings through IDX Broker. Provide community OR zipcode (zipcode overrides community). listingIds overrides every filter except sort. Sort 'pra' requires mip; sort 'sqfta' requires sqft. Returns up to 25 results by default plus a searchURL to share with the client.
| Name | Required | Description | Default |
|---|---|---|---|
| beds | No | ||
| sort | No | How to sort the results (note that only the top 25 will be returned by default); newest = newest listings, oldest = oldest listings, pra = least expensive to most (requires minimum asking price parameter), prd = most expensive to least, bda = bedrooms (low to high), bdd = bedrooms (high to low), tba = bathrooms (low to high) tbd = bathrooms (high to low), sqfta = square footage (low to high, requires sqft parameter), sqftd = square footage (high to low) | |
| sqft | No | Required when sorting by low-to-high square footage | |
| baths | No | ||
| limit | No | Maximum number of results to return (default: 25) | |
| daysOld | No | Maximum number of days since the listing was created | |
| zipcode | No | ||
| community | No | ||
| furnished | No | Leave blank for 'No Preference' | |
| yearBuilt | No | Set to current year for 'New Construction' | |
| listing_ids | No | Exact MLS listing IDs to look up directly | |
| maximumPrice | No | ||
| minimumPrice | No | Required when sorting by low-to-high price | |
| pets_allowed | No | Leave blank for 'No Preference' | |
| property_type | No | The sub-category of properties to include in the search; sfr = Single Family Residential, rnt = Rental, lse = Lease | |
| hoa_preference | No | Leave blank for 'No Preference' | |
| propertySubType | No | Overrides property_type | |
| community_feature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive/openWorld, so the safety profile is covered. The description adds non-obvious behavior beyond that: a 25-result default cap and the fact that a shareable searchURL is returned alongside results — a side output an agent would not otherwise predict. It stops short of explaining how to page past 25 or what happens when filters conflict beyond the stated precedence.
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?
Five short sentences with zero filler, front-loaded with what the tool does before the constraint rules. Slight cost in terseness: 'mip' and 'listingIds' do not match the schema's minimumPrice/listing_ids, so a reader must translate.
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 an 18-parameter, no-output-schema search tool, the description covers purpose, key filter interactions, sort preconditions, and the return shape (up to 25 results plus searchURL). Gaps remain around undocumented simple params (beds, baths, zipcode as an integer, community_feature) and how to retrieve results beyond the default 25, but the essentials for a correct first call are present.
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?
With 67% schema coverage and 18 params, the schema does much of the work (sort enum, property_type, furnished, yearBuilt are documented). The description adds genuine value the schema lacks: filter precedence (zipcode beats community, listing_ids beats everything but sort) and the sort-dependent required companions. It leaves beds/baths/zipcode/community_feature semantics unexplained, and refers to 'listingIds'/'mip' rather than the actual parameter names listing_ids/minimumPrice.
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 a specific verb+resource+source: 'Search Florida listings through IDX Broker.' That clearly separates it from sibling tools like listing_details (single-listing lookup) or save_listings, though no sibling is named explicitly. The scope (Florida, IDX-fed) is concrete 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?
Gives real operational routing rules: 'Provide community OR zipcode (zipcode overrides community)', 'listingIds overrides every filter except sort', and preconditions tying 'pra' to minimum price and 'sqfta' to sqft. It does not say when to choose this tool over listing_details or save_listings, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload the user's contact information to U.S. Prime Realty's CRM
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the user (preferably full name | |
| notes | No | Notes that should be saved along with the contact from the agent | |
| address | No | ||
| contact | Yes | At least ONE OF email/phone is required | |
| message | No | Additional message or notes from the user | |
| interestedIn | No | The type of property/properties the user is interested in; i.e. Waterfront Homes, School-Zone Properties, Pre-Construction Condos, Gulf Access, Pool Homes, New Builds, Waterfront Only, High-Rise Condos, Gated Communities, New Construction, Beachfront Condos, Gated Homes | |
| targetLocation | No | The location the user is interested in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the destination is an external CRM ('U.S. Prime Realty's CRM'), which is useful context, but says nothing about duplicate handling, whether contacts are created or updated, or authentication needs.
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?
A single efficient sentence with the core action front-loaded and zero waste. It is appropriately short, though it borders on sparse for a tool with seven parameters.
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 mutation tool with a nested contact object, no output schema, and seven parameters, the description leaves the agent without any expected return value or post-call behavior. The rich schema compensates for field semantics, but the lack of outcome information is a real gap.
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 86%, so the schema already documents nearly all seven parameters, including the nested contact object and its email/phone constraint. The description adds no parameter-level detail beyond the schema 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 gives a clear verb ('Upload') and resource ('contact information to U.S. Prime Realty's CRM'), so an agent knows exactly what the tool does. It doesn't differentiate from siblings such as notify_agent, but the purpose itself is 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?
There is no guidance on when to use this tool versus alternatives like notify_agent or book_appointment, nor any prerequisites or exclusions. The agent must infer the usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
affordability_calculatorbook_appointmentcancel_appointmentdownload_guidesget_appointment_slotsget_guides_listlisting_detailsmortgage_calculatornotify_agentreschedule_appointmentsave_listingssearch_propertiessend_contact_infoFree AI-run real estate CRM. Brokers: Florida recruiting lists, County Watch, auto email, BYO MLS.
Search live Phuket real estate: homes for sale, long-term rentals and new projects.
List on MLS, sell, show, compare and close your real estate property on beycome.
Puerto Rico & Colombia real estate: listings, sales, parcels, permits, analytics, AVM reports.
Add one secure layer between your agents and this server.
