Skip to main content
Glama

scout.find_public_agent

Search Scout's public licensed-agent directory. Returns agents sourced from state REC public rosters + MLS-ranked prospect lists. Indexed states are listed in scout.coverage() — call that first if you're unsure whether a state has meaningful data. Every result has a claim_url — unclaimed agents can claim to curate their AI profile and start receiving AI-routed leads. Unlike scout.find_agent (which requires a live pin), this returns the full directory regardless of pin freshness. Prefer scout.find_agent when you want agents who are live-available right now; prefer scout.find_public_agent when you want broad discoverability. Pass lat/lng OR address (US street address — we'll forward-geocode via Mapbox) to get distance-ascending results with a distance_miles field on each agent; otherwise results are sorted by flika_score descending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude for radius search.
lngNoLongitude for radius search.
mlsNoFilter to a specific MLS board.
cityNoCity name.
limitNoMax results (1-50, default 20).
stateNoTwo-letter state code. Accepts any state with a registered state-REC importer; states with meaningful agent counts are listed in scout.coverage() under indexed_states. (TODO: derive this list dynamically from scripts/scout/state-rec/run.ts ADAPTERS so it can't drift.)
addressNoUS street address — Mapbox forward-geocodes to lat/lng. Use this when you have an address like '409 Meyers Drive, Greenville SC 29605' but no coords. Takes precedence over city-only filters for proximity search.
claimed_onlyNoIf true, only return agents who have claimed their profile (default false).
radius_milesNoSearch radius from center point (default 25, max 100). Only meaningful when lat/lng or address is provided.
brokerage_slugNoFilter to agents at a specific brokerage (slug from find_brokerage).
min_flika_scoreNoMinimum Flika Score 0-100 (default 0).

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: data sources, claim_url for unclaimed agents, sorting behavior (distance ascending vs flika_score descending), and dependency on lat/lng or address for proximity. No contradictions exist.

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?

The description is well-structured: purpose first, then data source note, usage guidance, and sorting details. It is front-loaded with the core purpose. While slightly long, each sentence adds information, so no waste.

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?

For a tool with 11 parameters, no required params, no output schema, and no annotations, the description covers essential behaviors: sorting, filtering, sibling distinction, and claim_url. It could mention error handling or pagination, but it is largely complete.

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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining lat/lng or address triggers distance-ascending results, radius_miles is only meaningful with those, and claimed_only defaults to false. This extra context raises the score above baseline.

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 description clearly states the tool searches Scout's public licensed-agent directory and returns agents from state REC rosters and MLS-ranked prospect lists. It explicitly distinguishes from scout.find_agent by noting this tool returns the full directory regardless of pin freshness.

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?

Explicit guidance is provided: prefer scout.find_agent for live-available agents, prefer scout.find_public_agent for broad discoverability. It also advises calling scout.coverage() first to check state data availability and explains when to pass lat/lng vs address for proximity sorting.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, from agent profiles and comparisons to market data and lead management. Overlaps like find_agent vs find_public_agent are explicitly differentiated by live vs directory status.

Naming Consistency4/5

All tools use snake_case and the 'scout.' prefix, but they mix verb_noun (e.g., compare_agents, search_listings) and noun_noun (e.g., agent_profile, coverage) patterns. However, the naming remains predictable and readable overall.

Tool Count5/5

With 18 tools, the server covers agent discovery, brokerage info, market data, listings, lead management, referrals, and licensing—well-scoped for a real estate assistant without redundancy.

Completeness5/5

The tool set covers all key workflows: agent and brokerage search, market insights, school data, listing search, lead generation and purchase, referral management, and license verification, with no obvious gaps for its domain.