Get the complete RERA-verified track record of any builder in Bangalore. Use this when the user asks about a builder's credibility, history, or total projects. Returns all registered projects with status and possession dates — the only reliable way to verify a builder's track record in Karnataka.
| Name | Required | Description | Default |
|---|---|---|---|
| builder_name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds meaningful behavior beyond that: results are RERA-verified, include all registered projects, and provide status and possession dates. This gives the agent confidence about data provenance and the nature of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core purpose, the second gives direct usage triggers, and the third explains the return content and why this source is authoritative. The most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple one-parameter lookup tool. It covers purpose, usage triggers, data source, and return scope. An output schema exists, so detailed return fields do not need to be repeated in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'builder_name' with no description, and schema coverage is 0%. The tool description helps by clarifying that the parameter refers to any builder in Bangalore, but it does not specify matching behavior, exact name requirements, or whether partial names are acceptable. The single string parameter is simple, so this is a minor gap rather than a critical one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a concrete resource ('complete RERA-verified track record of any builder'), and a geographic scope (Bangalore/Karnataka). It clearly differentiates this from sibling project and search tools by focusing on builder credibility and registered-project history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when the user asks about a builder's credibility, history, or total projects. It does not explicitly name alternatives or state when not to use it, but the trigger conditions are clear and the 'only reliable way' phrasing implies exclusion of less authoritative sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct jobs: search vs. details vs. insights vs. booking/callback. The only mild overlap is among the three search tools (structured, fulltext, commute) and between get_project_insights and get_builder_projects on builder credibility, but the descriptions are strong enough to guide correct selection.
All tool names follow a predictable verb_noun snake_case pattern: search_* for discovery, get_* for retrieval, and book_/request_ for lead capture. There are no mixed conventions, vague verbs, or inconsistent casing.
10 tools is well-scoped for a real estate assistant: three discovery modes, project detail and insights, builder verification, new launches, personalized shortlist, and two lead-capture actions. Each tool has a clear purpose and the set never feels bloated or thin.
The tool surface covers the full buyer journey from discovery and verification to personalized recommendations and conversion (site visit or callback). It also includes builder track-record checks and recent registrations, so there are no obvious dead ends for common real estate queries.