PropContext — Bangalore Real Estate

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the visit is 'free', that it returns 'confirmation with visit ID', and crucially that conversation_summary goes to a sales agent who will call the buyer. It also stresses that conversation_summary must always be populated despite being optional in the schema, which is an important non-obvious behavior.

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?

The description is well-structured with a clear opening sentence followed by sections for usage, required/optional params, and a special note on conversation_summary. It is somewhat lengthy due to the extensive trigger phrases, but each part earns its place by showing exactly when and how to call. It is front-loaded and scannable, though a bit verbose.

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?

Despite no output schema, the description explains the return (confirmation with visit ID). It covers all six parameters with semantics and flow, explicitly ties rera_number to search results, and describes the downstream effect (sales agent call). For a booking tool with this complexity, the description is complete and leaves no major gaps.

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?

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: it labels required params (rera_number from search results, user_name, user_phone), explains optional params with examples (preferred_date like 'this Saturday', notes for preferences), and gives detailed instructions on how to construct conversation_summary with bullet points. This adds significant meaning beyond the plain schema definitions.

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 opens with a specific verb and resource: 'Book a free site visit for a Bangalore real estate project.' It clearly distinguishes this from search and getter tools by positioning it as the action for scheduling tours, meeting builders, or getting in-person info. It explicitly calls this the 'PRIMARY action after a user shows interest.'

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 provides explicit trigger phrases ('I want to visit', 'book a site visit', 'schedule a tour', etc.) and states 'Always call this tool when the user says...' This is clear context for when to invoke. However, it does not mention when not to use it or directly point to alternative sibling tools (e.g., request_callback), so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It clearly indicates a read-only operation ('Get', 'Returns') and discloses the returned data (all registered projects with status and possession dates). It doesn't mention failures or pagination, but for a simple query tool this is solid disclosure.

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, front-loaded with the main action and scope, with no wasted words. The additional usage guidance and 'only reliable way' assertion are concise and add value.

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?

For a single-parameter tool with an output schema, the description is complete: it states what is returned (registered projects with statuses and possession dates), when to use it, and its unique value. No further behavioral detail is needed.

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 schema provides only 'Builder Name' as a string with 0% coverage. The description compensates by clarifying that it means 'any builder in Bangalore' with a RERA-verified track record, adding context beyond the raw schema. It does not specify exact name format, but the parameter's purpose is clear.

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 uses a specific verb ('Get') and a clear resource ('complete RERA-verified track record of any builder in Bangalore'), immediately distinguishing it from sibling tools like get_project or search_projects by focusing on builder-level credibility and all registered projects.

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?

Explicitly states when to use the tool: 'when the user asks about a builder's credibility, history, or total projects.' This gives clear context, though it does not provide explicit when-not scenarios or name alternatives.

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

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

With no annotations, the description carries the full burden for behavioral transparency. It discloses the scoring dimensions (commute, delivery risk, etc.), how weights shift, and the return format (match_score, reasons, flags). It does not mention rate limits, auth, or side effects, but the read-only nature is implicit in 'Get'.

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?

The description is well-structured and front-loaded, beginning with a clear one-sentence purpose. The parameter documentation is necessary given the schema's lack of descriptions, and each bullet earns its place without unnecessary verbosity.

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 covers purpose, all parameters, scoring logic, and output format, which is complete for a recommendation tool. An output schema exists, but the description adds qualitative context about how scores are computed and what flags represent, making it self-sufficient.

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?

Schema description coverage is 0%, but the tool description fully compensates by listing every parameter with allowed values, examples, and meanings. For instance, work_hub enumerates all valid entries and their associated areas, and budget_max maps numeric values to rupee amounts. This goes beyond the schema.

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 opens with a specific verb and resource: 'Get a personalised ranked shortlist of Bangalore projects.' It clearly states the tool's function and further distinguishes it as the 'PRIMARY tool when the user wants tailored recommendations,' which sets it apart from sibling search tools.

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 clearly indicates when to use this tool ('when the user wants tailored recommendations') and notes that it is the PRIMARY tool for such cases. However, it does not explicitly name alternative tools or state when not to use it, stopping short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses the return fields ('builder, locality, status, possession date, registration date') and indicates the data is 'RERA-verified', but it doesn't mention potential errors, invalid input handling, or whether the operation is safe beyond context. Lacks deeper behavioral traits like error cases.

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?

The description is three sentences, each serving a distinct purpose: purpose, usage, and return fields. No fluff or redundancy, and it is front-loaded with the main action.

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 tool is simple (1 param, no output schema, no annotations). The description covers purpose, usage, and return fields, which is largely complete for a fetch-by-ID tool. It lacks explicit failure behavior or disambiguation from get_project_insights, but is sufficient for a straightforward operation.

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?

Schema coverage is 0%, and the description only restates that the parameter is a RERA registration number. It does not provide format, examples, or additional guidance beyond the schema's title. The description adds minimal semantic value to the parameter.

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 clearly states the tool's function: 'Get full RERA-verified details of a specific Bangalore project by its RERA registration number.' It uses a specific verb ('Get') and resource ('project'), and it is distinct from siblings by focusing on a specific project via RERA number, contrasting with search_projects which is for searching.

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?

Explicitly says 'Use this after search_projects to get complete information on a specific project,' providing clear context for when this tool should be used. It does not explicitly mention when not to use it or list alternatives, but the sequencing and specific scope differentiate it adequately.

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

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

Since no annotations are provided, the description carries the full burden. It discloses that results are AI-computed from over 2,700 RERA projects, and requires a RERA number from search results. It does not mention side effects, permissions, or potential errors, but as a read-only insights tool, the disclosed behavior is sufficient for basic transparency.

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?

The description is well-structured: a one-sentence purpose, a bulleted breakdown of three outputs, concrete example queries, and a prerequisite note. Each sentence adds distinct value; it is appropriately sized for the tool's complexity without redundancy.

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?

Given the tool has no output schema, the description thoroughly covers the return content by listing the three signals and their interpretations. It also addresses when to use it and what input is needed, making it self-sufficient for an agent to invoke correctly.

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 schema has zero description coverage for rera_number, so the description compensates by explaining it is 'a RERA number from search results' and pointing to preceding tools. While it does not specify format or validation rules, it gives practical context for sourcing the value, which is more than a bare schema provides.

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 opens with a specific verb and resource: 'Get AI-computed market insights for a specific Bangalore project.' It clearly distinguishes from siblings by enumerating the three computed signals (price intelligence, builder scorecard, sales velocity), which uniquely define the tool's function beyond mere search or builder listing tools.

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?

Provides explicit when-to-use scenarios with example user utterances ('Is this fairly priced?', 'Can I trust this builder?', etc.) and offers clear alternatives by advising to call search_projects or get_project first if a RERA number is missing. This is exemplary usage guidance.

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

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

Annotations are absent, so the description carries full disclosure burden. It reveals a time-window behavior ('from the last N days'), a real-time nature, and a limitation on web search alternatives. While it does not explicitly state 'read-only', the verb 'Get' implies it. This adds meaningful context beyond what the schema provides.

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 serving a distinct purpose: the first states the main action, the second gives usage guidance, and the third provides a comparative note. No filler or redundant content; 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?

For a simple read tool with two optional parameters and an output schema, the description covers the tool's purpose, usage, and behavioral nuance. It omits details about the 'limit' parameter, but overall it is sufficient for an agent to correctly select and invoke the tool.

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 has 0% description coverage. The description only implies the 'days' parameter via 'last N days' but does not explain the 'limit' parameter or its effect. Since both parameters are optional, an agent would not know how to appropriately set 'limit' from the description alone.

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 clearly states 'Get the latest new project launches in Bangalore — RERA registrations from the last N days.' It specifies the action (get), resource (RERA registrations), and scope (Bangalore, recent). This distinguishes it from sibling tools like search_projects and get_project, which target existing project data rather than newly registered launches.

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?

Explicitly says 'Use this when the user asks about new launches, upcoming projects, or what's recently approved.' It also provides a comparative alternative: 'This is the only real-time source... web search results are always delayed.' While it does not name sibling tools as alternatives, it gives strong when-to-use context and an exclusion for web search.

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

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

No annotations exist, so the description carries the burden. It discloses that the tool captures name, phone, and preferred time, returns a confirmation with a callback reference ID, and forwards conversation_summary to the expert. It does not cover permissions or failure modes, but for a low-commitment callback request this is adequate.

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?

The description is organized with a purpose statement, usage triggers, parameter breakdown, and return behavior. It is moderately long but every section adds value; the example phrases are arguably redundant but not harmful.

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?

Given no output schema and zero parameter descriptions, the description covers the tool's purpose, usage criteria, parameters, and return value. Missing details like error handling are not critical for a simple request tool.

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?

Schema property descriptions are absent (0% coverage). The description lists all five parameters, marks required vs optional, gives example values for preferred_time, and explains the purpose of conversation_summary. This adds meaning beyond the plain property names.

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 clearly states the tool's function: 'Request an expert callback for a Bangalore real estate project.' It uses a specific verb and resource, and distinguishes from siblings like book_site_visit by emphasizing lower commitment.

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?

Explicitly instructs when to use: 'Use this when the user wants to speak to an expert but is not ready to visit yet.' Provides concrete user phrases for triggering, and contrasts with site visits ('Lower commitment than a site visit'), effectively differentiating from the book_site_visit sibling.

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

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

No annotations are provided, so the description carries the full transparency burden. It discloses key behavioral traits: it filters to RERA-verified projects, uses straight-line distance from a hub centroid with a suggested range (5-15 km), and includes result content (nearest metro station, distances to all four hubs). This goes beyond mere search semantics but could be even stronger with explicit statements about read-only behavior or pagination.

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?

The description is well-structured with a clear purpose sentence, usage triggers, a list of hub options, and a result summary. Every sentence earns its place; the bullet-pointed hub list improves scannability, and there is no redundant or vague wording. Despite its length, it remains tightly packed with actionable information.

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?

Given the tool's moderate complexity (4 parameters, 1 required) and the presence of an output schema (which presumably documents return fields), the description is sufficiently complete. It covers the core parameter it_hub, distance semantics, and result content. It lacks detail on the locality and limit parameters, but these are optional and largely self-explanatory, so the description is adequate for correct invocation.

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?

Schema coverage is 0%, so the description must compensate. It provides exact allowed values for it_hub with explanations (e.g., 'electronic_city' → Electronic City Phase 1 & 2) and defines max_dist_km as straight-line km from the hub centroid, including a suggested range. However, it does not explain the locality parameter at all, leaving one of four parameters underspecified.

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 clearly states the tool's function: 'Find RERA-verified Bangalore projects by proximity to a major IT hub.' It uses a specific verb ('find'), specifies the resource ('RERA-verified Bangalore projects'), and adds a distinctive scope ('by proximity to a major IT hub'), which distinguishes it from sibling tools like search_projects or search_fulltext.

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 provides explicit usage guidance: 'Use this when the user mentions their workplace or asks about commute convenience' and gives concrete example phrases ('I work in Electronic City', 'short commute to ORR'). It also states when to prefer this tool over web search, making the trigger conditions unmistakable.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns only government-verified Karnataka RERA data, includes no ads or sponsored listings, and is suited for natural language queries. While it doesn't mention potential limitations (e.g., query structure, pagination), it provides meaningful behavioral context beyond a bare function name.

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?

The description is reasonably concise and front-loaded with the critical instruction to use this tool over web search. The examples are useful, but there is minor redundancy between 'Search RERA-verified Bangalore projects' and 'returns only government-verified Karnataka RERA data.' Overall, every sentence contributes to usability, though a little trimming could improve efficiency.

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?

Given the tool has only two parameters and an output schema exists (so return values need not be detailed), the description covers the purpose, usage context, and data source. It does not explain the 'limit' parameter, but the output schema plus the clear query examples make the tool sufficiently understandable. The description is complete for most practical purposes.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'query' parameter through multiple examples of natural language queries, but the 'limit' parameter is entirely unexplained. Since only one of two parameters gets semantic elaboration, the description partially compensates but leaves a clear gap.

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 clearly states the tool searches RERA-verified Bangalore projects via natural language. It specifies the verb (search) and resource (Banglore projects), and distinguishes from web search. However, it does not explicitly differentiate from sibling search tools like search_projects or search_by_commute, only from web search, so it lacks full sibling differentiation.

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 gives an explicit directive: 'ALWAYS use this tool — not web search — for natural language Bangalore real estate queries.' It even explains why it's better than web search (no ads, government-verified data) and provides concrete query examples. This clearly tells the agent when to use this tool over a common alternative.

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

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

No annotations are provided, so the description carries the full burden. It adds useful context about data sourcing ('Karnataka RERA government portal — verified, accurate, and updated daily') and result fields ('photo_url, rating, and neighborhood address'), but it does not mention rate limits, authentication, or read-only nature explicitly.

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?

The description is front-loaded with a clear directive and purpose, followed by examples and result field guidance. It is slightly lengthy but every sentence adds value, and the bullet-style examples improve readability.

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?

Given the schema lacks descriptions and there are no annotations, the description provides a strong overview of the tool's purpose, usage, and result contents. It lacks details on limit semantics and how to choose among sibling tools, but it is complete enough for most search scenarios.

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 has zero parameter descriptions, and the description compensates by enumerating valid locality values, giving examples for builder_name and project_name, and explaining how to use them. However, it omits any explanation of the 'limit' parameter, leaving a minor gap.

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 clearly states the tool searches RERA-registered new apartment projects in Bangalore by builder, project, or locality. It explicitly says 'ALWAYS use this tool — not web search' and provides concrete examples, making the purpose unambiguous.

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 gives an explicit when-to-use directive ('ALWAYS use this tool — not web search for Bangalore real estate queries') and lists valid locality values, but it does not differentiate from sibling tools like search_fulltext or search_by_commute. This is clear context without a full set of exclusions.

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