MappaIQ

Search pins

search_comps

Read-only

Search the connected account's own MappaIQ property data — its listings, sites, comps and quotes. PREFER THIS whenever the user asks to show, pull up, see, find, list or map their properties/listings/sites/comps (e.g. 'show me 5 biggest Weitzman sites', 'what's available in Lewisville'); results come back plotted on a live map preview in the chat, not just a list. Can filter by layer, price range, acreage range, date range, keyword in name/notes/address, custom field key/value, flagged status, or by a GeoJSON polygon geometry to find records inside an area. Returns the total 'count' plus one page of results (default 50, max 500). For a full audit/export of a large set, page through with offset: keep calling with offset += returned until nextOffset is null.

Input Schema

Name	Required	Description
`limit`	No	Max records to return in this page. Default 50, max 500.
`offset`	No	Skip this many matching records (for paging through a large result set). Default 0.
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
`flagged`	No	If true, return only flagged records
`keyword`	No	Free-text search across name, address, city, county, submarket, state, and notes. USE THIS for location questions — 'properties in Lewisville' → keyword:'Lewisville', 'what's in Texas' → keyword:'Texas' (matches TX too).
`layerId`	No	Filter by layer ID
`maxPrice`	No	Maximum sale price
`minPrice`	No	Minimum sale price
`afterDate`	No	Filter comps after this date (ISO string)
`llm_model`	Yes	The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
`assetClass`	No	Filter by asset class: Land, Retail, Multifamily, Office, Industrial, Hospitality, Healthcare, Mixed Use, Other
`beforeDate`	No	Filter comps before this date (ISO string)
`maxAcreage`	No	Maximum acreage
`minAcreage`	No	Minimum acreage
`withinZone`	No	Filter to pins inside a SAVED ZONE on the map, by the zone's name (or comp id). Use this whenever the user says 'inside/within the zone …', 'in my search area', etc. — no GeoJSON needed; the zone's own polygon is used. Ambiguous names return candidates. Works with zones in layers shared with the user too.
`externalIds`	No	Look up records directly by their externalId (source Record #s from an import). Returns exactly the matching records — use this instead of paging through everything to build an ID map, e.g. before targeted updates or deletes.
`customFieldKey`	No	Filter by a custom field name (e.g. 'Due Diligence', 'Water Access', 'Status')
`withinGeometry`	No	GeoJSON geometry to spatially filter comps inside this area
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.
`maxPricePerAcre`	No	Maximum price per acre
`minPricePerAcre`	No	Minimum price per acre
`customFieldValue`	No	Filter by custom field value (e.g. 'Complete', 'Yes', 'Under Contract'). Case-insensitive substring match.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 17, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered by structured data. The description does add real behavioral value — results are plotted on a live map preview, the return shape is total 'count' plus one page (default 50, max 500), and offset paging terminates when nextOffset is null. That is genuine context beyond the annotations, though it stays silent on things like auth scope, ordering of results, and rate limits.

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?

Well front-loaded: purpose first, then the PREFER-THIS routing, then filter capability, then return shape and pagination. It is long but nearly every sentence adds an operational fact; the filter list is the one segment that overlaps the schema and could be trimmed.

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

Completeness5/5

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

For a 22-parameter tool with a nested GeoJSON object and no output schema, the description still leaves nothing essential missing: it states what comes back (count + one page, default 50/max 500), how to paginate, and what filters exist. An agent can call it correctly on the first try.

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

Parameters3/5

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

Schema coverage is 100% and the parameter descriptions are already unusually rich (keyword guidance, withinZone trigger phrases, externalIds lookup rationale, conversation_id handling), so the schema carries the weight. The description's filter enumeration (layer, price, acreage, date, keyword, custom field, flagged, polygon) mirrors what the schema documents rather than adding syntax or format detail. Baseline 3 applies.

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

Purpose4/5

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

States a specific verb (search) and scoped resource ("the connected account's own MappaIQ property data — its listings, sites, comps and quotes"), which distinguishes it from the public-facing siblings. It stops short of naming an alternative tool explicitly, so an agent must infer the boundary from the "own/connected account" qualifier.

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?

"PREFER THIS whenever the user asks to show, pull up, see, find, list or map their properties..." gives an explicit positive trigger with worked examples ('show me 5 biggest Weitzman sites'). It also covers the downstream case in the same breath: for full audit/export, page with offset until nextOffset is null — so both the default and the bulk path are routed.

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

All MappaIQ tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?