Skip to main content
Glama
mambalabsdev

Agent to Brokerage Resolver MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Resolve agent brokerage

resolve_agent_brokerage
Read-onlyIdempotent

Resolve a licensed US real estate agent to their brokerage of record, or list active agents at a firm or offices in a ZIP code. Returns agent counts, size bands, and license status and expiry.

Instructions

Look up a licensed US real estate agent on the official state license register and get the brokerage of record, the brokerage's active agent count and size band (1, 2-15, 16-50, 51+), and the agent's license status and expiry. Covers 19 states; brokerage data in CA, IA, MO, NV, NY, OH, OR, TX, and VT. Three modes: lookup (one agent or a list, by license number or by name), roster_firm (active agents at one brokerage), and roster_zip (brokerage offices in a zip code, NY, MO, OR, and VT). Returns no emails, phone numbers, or home addresses. Ambiguous or unmatched inputs return a free row with row_status explaining why. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN and consumes Apify credits per matched row.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
zipNoroster_zip mode. A five digit zip code.
cityNoLookup mode: narrows a name match by the brokerage office city or the license county.
modeNolookup finds one agent or a list. roster_firm lists the active agents at one brokerage. roster_zip lists brokerage offices in a zip code (NY, MO, OR, VT). Default lookup.
zipsNoroster_zip mode, many at once. One zip code per line.
stateNoTwo letter licensing state, for example TX. Used with license_number, agent_name, or the brokerage fields.
agentsNoLookup mode, many at once. One per line: state | name | brokerage (optional) | city (optional).
licensesNoLookup mode, many at once. One per line: state then license number, for example TX 0123456.
agent_nameNoLookup mode, when there is no license number. First and last name. Add brokerage_name or city to narrow a common name.
active_onlyNoRoster modes. List only agents with an active license. Default true.
max_resultsNoRoster modes. Most rows one brokerage or zip returns, 1 to 1000. Default 100.
brokerage_nameNoLookup mode: narrows a name match. roster_firm mode: the brokerage to list, by its exact registered name.
include_agentsNoroster_zip mode. true also lists the active agents at each office. Default false.
license_numberNoLookup mode. The agent's license number as the state register prints it, for example 134224-SA. The most reliable lookup.
max_charge_usdNoOptional. The run stops before the row that would take its charges over this amount.
brokerage_license_numberNoroster_firm mode. The brokerage's license number.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, open-world, idempotent, non-destructive, so the safety profile is covered; the description then adds substantial extra context: no emails/phones/home addresses are returned, ambiguous or unmatched inputs return a free row with row_status, failed runs return an error with a run ID, an APIFY_TOKEN is required, and Apify credits are consumed per matched row (with max_charge_usd truncating the run).

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?

It is a single dense but well front-loaded paragraph where essentially every clause carries information (modes, coverage, privacy, errors, auth, cost). It could be easier to scan with the mode/coverage/privacy facts broken out, but there is no filler.

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 15-parameter, three-mode, no-output-schema tool, the description supplies the return contents, geographic limitations, per-call cost/auth requirements, and error/ambiguity behavior, which is everything an agent needs to invoke it correctly without an output schema.

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 description coverage is 100%, so the baseline is 3 and the schema already documents all 15 parameters including mode, per-line formats, and defaults. The description adds the size-band breakdown (1, 2-15, 16-50, 51+) and per-mode state coverage, but little parameter syntax beyond the schema.

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?

The opening sentence states a precise verb and resource ('Look up a licensed US real estate agent on the official state license register') and enumerates the concrete outputs (brokerage of record, active agent count, size band, license status and expiry). An agent immediately knows what this tool returns and the scope of the data.

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?

It explicitly names the three operating modes and the condition selecting each: lookup (one agent or a list, by license number or name), roster_firm (active agents at one brokerage), and roster_zip (offices in a zip, NY/MO/OR/VT). It also states coverage boundaries ('Covers 19 states; brokerage data in CA, IA, MO, NV, NY, OH, OR, TX, VT'), which steers the agent away from unsupported queries.

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