Skip to main content
Glama

lead_score

Score a website lead (the Minhelet lead form): the lead-quality score 0 to 10 from the form fields, combined with the Asset Analyzer feasibility of its building (final = round(0.4 x quality + 0.6 x feasibility), capped at 3 for NO-GO and 7 for GO-WITH-CAUTION) and its tier (חם, חמים, קר, חלקי, זבל, or מחוץ לביקוש). Before any GO or hot/warm tier the city is checked against city_demand (same source as GET /api/demand-cities/lookup). A known non-demand city or an unknown city (demand_city false or known false) is not GO: tier מחוץ לביקוש, decision OUTSIDE-DEMAND, dial_allowed false. The numeric score stays in lead_quality_score and reasons. If the demand table cannot be read, demand_city is null and the tier is not forced. With analyze: true it starts the asset check of the lead's building and adjacent buildings (counts against the asset_analyze daily limit; junk leads are not checked); past wait_seconds it returns {pending, run_id}, then call lead_score again with the same lead and that run_id. Without either, it scores lead quality alone.

Input Schema

NameRequiredDescriptionDefault
leadYesThe lead form body as the website posts it (first_name, last_name, email, phone, city, street, building_number, building_units, building_floors, project_status, has_active_project, has_active_representation, adjacent_buildings_addresses, resident_consensus, known_opponents, has_signed_poa, message, ...).
run_idNoThe run_id an earlier lead_score or asset_analyze returned: combine with that check.
analyzeNoStart the asset check of the lead's building(s).
wait_secondsNoWith analyze: how long to wait before returning {pending, run_id} (default 50, max 290).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations the description carries the full burden and does so: it discloses the scoring formula and caps (3 for NO-GO, 7 for GO-WITH-CAUTION), the city_demand gating that forces tier מחוץ לביקוש with dial_allowed false, graceful degradation when the demand table is unreadable (demand_city null, tier not forced), that junk leads are not asset-checked, and the quota side effect.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is a single dense run-on block of parentheticals and clauses with no separation between scoring, demand-gating, and async polling concerns. Most sentences earn their place, yet the structure makes it harder to scan than the content warrants.

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 4-param tool with a nested lead object, no annotations and no output schema, the description covers the key returned fields (lead_quality_score, reasons, tier, decision, dial_allowed, demand_city) and the pending/run_id shape. It leaves the full success payload and failure modes implicit, which keeps it short of 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 real meaning on top — wait_seconds default 50/max 290 already in schema, but the analyze quota cost, the junk-lead exclusion, and the run_id continuation protocol are behavioral semantics the schema does not state. It does not enumerate the lead sub-fields' influence beyond 'form fields', keeping it below 5.

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?

States a specific verb and resource ('Score a website lead') and immediately scopes it to the Minhelet lead form, distinguishing it from asset_analyze and the rest of the compound/planning siblings. The formula and tier vocabulary make the operation unmistakable.

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

Usage Guidelines4/5

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

Explicitly branches the usage: default scores quality alone, analyze:true also starts the asset check and consumes the asset_analyze daily quota, and exceeding wait_seconds returns {pending, run_id} requiring a re-call with that run_id. Missing only an explicit steering statement for when to prefer asset_analyze on its own rather than through this tool.

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.

Resources