Agent to Brokerage Resolver MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | An Apify API token from console.apify.com/account/integrations. The server lists its tool without a token, but a tool call needs one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_agent_brokerageA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With a single tool, there is no possibility of misselection between tools. The tool's purpose (resolving an agent to a brokerage via three explicit modes) is unambiguous.
The sole tool uses a clear snake_case verb_noun pattern (resolve_agent_brokerage). With only one tool there is no internal inconsistency, and the name is readable and domain-specific.
One tool for an entire server is on the thin side; the three modes are packed into a single tool rather than exposed as separate operations. It is defensible for a narrow resolver, but by the stated guidance 1-2 tools is borderline.
The lookup, roster_firm, and roster_zip modes cover the main access patterns for agent and brokerage data. Minor gaps exist (e.g., no direct supported-states/coverage query or explicit brokerage lookup by name), but core workflows are covered.