Skip to main content
Glama
Sign In
onehome-mcp

onehome-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Fetch a saved search and inflate its listings in one call

onehome_get_saved_search_with_listings
Read-onlyIdempotent

Fetch a saved search and its full property listings in one call, returning filters, listing records, count, and pagination for a magic-link session.

Instructions

Combo tool: the "show me my saved homes" flow in a single round trip. Internally runs GetSavedSearchBySearchId to fetch the saved search (name, filters, polygon, listingIds) and then GetSavedListings to inflate those listingIds into full property records — the same two-call sequence as calling onehome_get_saved_search followed by onehome_search_properties(saved_search_id=...), but exposed as one tool so the magic-link-to-listings consumer flow is a single MCP call. Returns { saved_search, listings, count, page_info }. Both saved_search_id and group_id default to the magic-link session context. Sort defaults to property.MajorChangeTimestamp DESC (Newest). Listings are returned via the GraphQL listing-card projection (buildGetSavedListings), which does NOT include PublicRemarks — so there is no raw description to opt back into here. Use onehome_get_property(listing_id) per row when you need the full description for a specific listing. view: "brief" answers one line per listing instead: address · price — date of its last change — status, change (e.g. a new listing or a price decrease), inside the untrusted-data envelope as data: string[], with -- none for an empty saved search and -- N of M shown when the page holds fewer listings than the search.

Input Schema

NameRequiredDescriptionDefault
viewNo"full" (default) returns the saved search and its listing records; "brief" returns one line per listing: address · price — date of its last change (or "no date") — status, change — in the untrusted-data envelope, with "-- " note lines for an empty or partial page.
group_idNo
page_numNo
page_sizeNo
sort_fieldNoGraphQL dotted-path, e.g. property.MajorChangeTimestamp or property.ListPrice
sort_orderNo
saved_search_idNo
include_dislikesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.1
    • addedInput schema / properties / view
      Added value: +{
+  "description": "\"full\" (default) returns the saved search and its listing records; \"brief\" returns one line per listing: address · price — date of its last change (or \"no date\") — status, change — in the untrusted-data envelope, with \"-- \" note lines for an empty or partial page.",
+  "enum": [
+    "full",
+    "brief"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv0.13.1

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Genuinely adds behavior beyond the readOnly/idempotent annotations: the GraphQL listing-card projection omits PublicRemarks so there is no raw description, defaults are inherited from the magic-link session context, and default sort is property.MajorChangeTimestamp DESC. It also discloses the untrusted-data envelope and the placeholder lines for empty/partial pages.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and composition before diving into projection limits and view modes, and every sentence carries information. It is dense and slightly long – internal method names like buildGetSavedListings are noise for an agent – but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by naming the return shape { saved_search, listings, count, page_info } and describing brief-mode output precisely. The main gap is behavior of the unmentioned pagination and include_dislikes parameters, which matter for an 8-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 25% schema coverage, the description does real work: it explains saved_search_id and group_id defaulting to session context, the default sort field, and the two view modes with their output formats. It leaves sort_order, page_num, page_size and include_dislikes unaddressed, so pagination and dislike handling remain undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific framing ("combo tool" for the "show me my saved homes" flow) and names the exact composition: GetSavedSearchBySearchId then GetSavedListings. It explicitly contrasts with the sibling pair onehome_get_saved_search + onehome_search_properties, so an agent can distinguish it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States clearly when to use this over the two-call sequence (single MCP call for the magic-link-to-listings consumer flow), when to use onehome_get_property per row instead (needed PublicRemarks), and when to prefer view:"brief" (one line per listing). All three routing decisions are explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools