LTS MCP Server

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

With no annotations, the description carries full burden and discloses key behaviors: grouping by city+province to avoid name collisions, a 25k row cap, and the need to check a truncated flag. It also implies the ranking nature and output breakdowns. This goes beyond the schema and provides essential operational context.

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, front-loaded with the core purpose, then grouping behavior, then use cases and a warning. Every sentence adds unique value with no filler.

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 no annotations, the description provides strong context: it explains the output elements (province, region, law, active/expired split, top developer), the grouping behavior, the row cap/truncation caveat, and appropriate use cases. It is sufficiently complete on its own.

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 100% with detailed parameter descriptions, so baseline is 3. The description adds context that the tool produces breakdowns by law and region, which relates to how the law and region parameters shape output, and clarifies the limit's effect via 'sorted by count desc' in schema. It doesn't add new syntax but reinforces parameter roles.

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 the specific verb 'Rank' and names the resource 'cities by LTS count', with clear output breakdowns (province, region, law, active/expired, top developer). It differentiates from sibling tools like lts_by_region and lts_by_law by focusing on city-level aggregation and grouping by city+province.

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?

It explicitly states 'Use for housing pressure indices, city-level market analysis, and identifying emerging development hotspots', providing clear application scenarios. It also suggests cross-referencing with PSGC MCP, but does not name alternative sibling tools or state when not to use it, so it falls short of full exclusion 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?

With no annotations, the description carries the behavioral disclosure burden. It reveals the ranking mechanism, the data breakdowns, and a critical operational constraint (25k row cap) with a direct instruction to check the truncated flag and narrow filters. This is more than typical, though it stops short of covering authentication or error 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?

Two sentences, front-loaded with the core function and features, followed by use cases and a critical limitation. Every sentence earns its place with no redundancy or filler.

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 tool with no output schema and no annotations, the description covers purpose, usage context, and operational limitations (cap, truncated flag). The breakdown dimensions and use cases are sufficient for selecting and invoking the tool. Minor omission: no explicit mention of response format, but the description already hints at key output aspects.

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 100%, with thorough parameter descriptions (law enum, year range, limit default/max/sort, region string). The description adds context about the breakdowns but does not add syntax or format details beyond the schema, so the baseline 3 is appropriate.

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 states a specific action ('Rank developers') and resource ('by LTS count'), with concrete output dimensions (regional footprint, law breakdown, active/expired split). This clearly distinguishes it from sibling tools like lts_by_city or lts_by_region, which group by different attributes.

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 use cases ('developer intelligence, competitive analysis, identifying which developers dominate specific regions or housing segments') that imply when to use this tool over alternatives. It does not explicitly mention alternative tools or when not to use, but the context is clear enough.

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 provided, the description carries the full burden of behavioral disclosure and does so well. It reveals the 25k row cap, the truncated flag, the advice to narrow filters, and the conditional YOY calculation—details that are not visible in the input schema.

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: purpose, use case, and operational caveat. The description is front-loaded with the core function and contains no filler or redundant jargon.

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 having no annotations or output schema, the description provides sufficient context for an agent to decide when to call this tool and interpret potential output flags. It covers the tool's analytical purpose, the conditional behavior without a year filter, and the row cap/truncation handling—making it complete for a 2-parameter, 0-required 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 already provides 100% coverage for both parameters, so the baseline is 3. The description does not add new parameter-specific details beyond the schema; it merely restates the year-omit behavior that the schema already documents.

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 immediately states the tool's function with a specific verb ('Break down') and resource ('LTS records by housing law'), and explicitly distinguishes the two law categories (BP220 vs PD957). This clearly differentiates it from sibling tools like lts_by_city or lts_by_region.

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 clear usage context: 'Use for housing policy analysis and socialized housing supply tracking.' It also explains the conditional year-over-year shift when no year filter is applied. However, it does not explicitly state when not to use this tool or name alternative sibling tools for exclusions.

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 provided, the description carries the full burden. It discloses the 25k row cap, advises checking a truncated flag, and suggests narrowing filters if truncation occurs—behavioral details beyond the schema. It doesn't explicitly confirm read-only behavior, but the aggregation language implies it. This is strong transparency for a reporting tool.

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 focused sentences: the first states purpose and outputs, the second gives use cases, the third covers limits and actionable advice. Every sentence earns its place with no redundancy or filler.

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, the description adequately explains the return values (count, market share, law breakdown, active/expired split). It also includes the cap/truncation context. It could go further by detailing ordering or region naming, but it is complete enough for a regional aggregation 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 schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no extra semantics beyond referencing law and status in the output context, which mirrors the existing parameter descriptions. It neither compensates for gaps nor contradicts 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 uses a specific verb 'Aggregate' with a clear resource 'LTS records by DHSUD region' and enumerates the exact outputs (count, market share, law breakdown, active/expired split). This clearly distinguishes it from sibling tools like lts_by_city, lts_by_developer, and lts_by_law, which focus on different grouping dimensions.

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?

It provides explicit use cases ('State of RE reports and regional housing market analysis') and even recommends cross-referencing with PSGC MCP for population data. However, it does not explicitly contrast with alternatives or state when not to use the tool, so it earns a 4 rather than 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 provided, the description carries the full transparency burden. It explicitly discloses the return behavior (whether the number exists in lts_records, project_lts, or both) and promises full record details when found. This gives an agent clear expectations, though it does not explicitly state that the operation is read-only or describe error 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 extremely concise—three short sentences that each add distinct information (purpose, sources checked, output details). It is front-loaded with the primary action and contains no redundant or ambiguous wording.

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 lookup with one parameter and no output schema, the description covers the essential aspects: what it does, which sources it checks, and what it returns when found. It does omit specifics about the 'not found' return format or any error conditions, but it is sufficiently complete for an agent to invoke the tool 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 input schema already provides 100% coverage for the single parameter ltsNumber, including an example format. The description only restates 'specific LTS number' and adds no new semantic details, so it meets the baseline but does not extend it.

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 a specific action (check if a specific LTS number exists), the resources involved (lts_records, project_lts), and the output (existence status and full record details). This distinguishes it from sibling tools that search by city, developer, law, etc., making the purpose unmistakable.

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 implies usage when an exact LTS number is known and existence needs verification, but it does not explicitly state when to choose this tool over alternatives like lts_search or lts_by_*. There is no mention of when not to use it or direct comparisons to sibling tools, so guidance is only implied.

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 fully discloses key behaviors: sorting by urgency, returning days remaining, providing summary counts by region/developer, and a 25k row cap with a truncated flag and advice to narrow filters. This exceeds typical disclosure and gives the agent critical operational knowledge.

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: purpose/returns, use cases, and capacity warning. The description is front-loaded and free of fluff.

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 return structure (sorted, days remaining, summary counts, truncated flag) and operational limits (cap, filter advice). It's complete for a tool of this complexity.

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 covers 100% of parameters, so baseline is 3. The description adds context by linking the 'days' parameter to the expiry window and mentioning 'narrow filters,' which implicitly describes how to use region/law parameters. It reinforces but doesn't duplicate schema details.

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 finds LTS records expiring within a specified timeframe, using a specific verb ('Find') and resource ('LTS records'). It differentiates from sibling tools by emphasizing expiry risk, urgency sorting, and summary counts, making its purpose distinct.

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?

It explicitly names use cases: 'compliance monitoring, renewal pipeline tracking, and risk assessment.' While it doesn't mention alternative tools or exclusions, the context is clear and sufficient for an agent to decide when to invoke this tool.

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 provided, the description carries the transparency burden. It discloses that the tool returns distinct regions and cities from the verification queue, optionally filtered by region. This gives useful behavioral context beyond a simple 'get filters' statement, though it doesn't describe the output format or edge 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 four concise, purposeful sentences. It front-loads the purpose, then covers the resource, optional parameter, and usage guidance with no redundancy or filler.

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 tool with one optional parameter and no output schema, the description is largely complete. It covers purpose, usage, and parameter semantics. However, it omits the response structure (e.g., whether the result is an array or an object), which would be useful given no output schema is present.

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 covers the region parameter, but the description adds semantic value by clarifying that regions are always returned while the region parameter filters only the cities. This goes beyond the schema's description of 'only return cities within this region.'

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 available filter values for LTS queries.' It specifies the resource (LTS queries) and the output (distinct regions and cities from the verification queue), distinguishing it from sibling data-query tools like lts_search or lts_by_region.

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 explicit usage context: 'Use this before calling lts_queue or lts_search with region/city filters to get valid values.' It names alternatives and specifies the timing, satisfying the requirement for when-to-use 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?

With no annotations, the description carries full burden. It discloses that computed fields (is_expired, days_until_expiry) and summary counts are returned, and that fuzzy matching applies to projectName. However, it omits any mention of side effects, authentication, rate limits, or error behavior for non-existent projects. The 'Get' verb implies read-only but is not explicitly stated.

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 two sentences, front-loaded with the core purpose and followed by parameter guidance. Every word earns its place; there is no redundancy, jargon, or filler. It is efficiently structured for an AI agent to parse quickly.

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, the description does a good job explaining what the tool returns: all LTS records, computed fields, summary counts, and the primary LTS number. It also covers the two parameter options. It does not address edge cases like no matches or multiple fuzzy hits, but the provided detail is sufficient for a simple lookup 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 description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it reinforces that either a UUID or fuzzy-matched name can be passed. The schema already documents both parameters, including the fuzzy lookup behavior and priority rule, so the description only restates existing information.

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 gets the complete LTS picture for a single project, specifying exact outputs (all LTS records, computed fields, summary counts, primary LTS number). This specific verb+resource phrasing distinguishes it from sibling tools like lts_by_city or lts_records, which focus on different dimensions.

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 clear context for when to use the tool: to retrieve data for a single project by passing either a UUID or name (fuzzy matched). However, it does not explicitly mention alternatives or when-not-to-use scenarios, though the sibling list implies other dimension-specific tools exist.

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 burden. It discloses that records are normalized and have confidence levels, and explains that linked status refers to has project_id. However, it does not mention default sorting, pagination behavior, or whether low-confidence records are excluded by default. Partial disclosure is present but gaps remain.

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 purpose, no filler. The filter list in sentence 2 is somewhat redundant with the schema, but the overall structure is clean and efficient.

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 has 9 optional parameters, no output schema, and no annotations. The description provides only a high-level view and does not address sorting, pagination, or relationships to sibling tools like lts_project or lts_by_developer. This incompleteness is significant for a complex browse 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 descriptions cover all 9 parameters with 100% coverage. The description adds a brief mapping ('linked status (has project_id)') and a specific use case for expiringWithinDays, but largely restates schema information. Per baseline rules, this scores 3.

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 the verb 'Browse' to indicate a read-only listing, specifies the resource as LTS records from DHSUD, and mentions normalized records with confidence levels. It lists filter categories but does not explicitly differentiate from sibling tools like lts_search or lts_by_region, so it's clear but not fully distinguished.

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?

It provides a specific use case ('Use expiringWithinDays to find records expiring soon') but gives no guidance on when to use lts_records instead of specialized tools like lts_by_region or lts_search. No exclusions or alternative references are mentioned.

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 provided, the description carries the full burden for behavioral disclosure. It reveals that results come from both lts_records and published projects, and that matches are returned, but it does not explain pagination behavior, result grouping, or read-only nature. The description is not misleading but adds only minimal behavioral context beyond the tool's 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 three concise sentences, each providing distinct value: what the tool searches, what it returns, and its role as a universal entry point. No redundancy or fluff, and all key 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 tool has a moderate complexity with multiple search dimensions and pagination, but no output schema. The description clarifies the data sources but does not describe the structure of matches (e.g., merged list vs. separate sections) or pagination behavior. While the schema covers parameters, the absence of output schema and limited behavioral detail leaves gaps for the agent to infer.

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 100% coverage, with each parameter (query, limit, offset) already described. The description's mention of searchable fields (name, LTS number, developer, city) mirrors the query parameter description, adding no new semantic value. Baseline of 3 is appropriate since the schema fully handles parameter clarity.

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 with a specific verb ('Search'), the resource ('DHSUD LTS records and published projects'), and the search dimensions (name, LTS number, developer, or city). The phrase 'Universal entry point for LTS data' distinguishes it from sibling tools that target specific filters like city or developer.

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 clear context that this is a broad search across all LTS data, implying it should be used for general queries or when the user is unsure of the specific category. However, it does not explicitly name sibling tools (e.g., lts_by_city) or state when not to use it, missing the explicit alternatives-level 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently details the two return sections and their contents, giving a clear picture of the output. It does not mention caching, permissions, or computation method, but for a read-only stats endpoint, this level is sufficient.

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 two sentences, front-loads the main purpose, and uses a clear numbered list for the return sections. Every word contributes value; there is no fluff or repetition.

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 simplicity (no parameters, no output schema), the description fully accounts for what the caller needs to know: the scope and the exact contents of the response. The sibling tool names further reinforce the system-wide vs. segmented distinction. No additional context is necessary.

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 tool has zero parameters, so there is no parameter semantics to explain. The baseline score of 4 applies because there is nothing that requires elaboration, and the description does not need to compensate for schema gaps.

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 begins with a specific verb and resource: 'Get system-wide LTS statistics.' It clearly distinguishes this tool from siblings like lts_by_city or lts_by_developer by emphasizing the system-wide scope. It also enumerates the exact return sections, 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 phrase 'system-wide' provides clear context for when to use this tool versus more narrowly scoped sibling tools. However, it does not explicitly name alternatives or state exclusions, so the guidance is implied rather than directly actionable. This is a minor gap.

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 provided, the description carries the full burden. It discloses a 25k row cap, truncated flag behavior, and return content (period counts, law breakdown, peak period, YoY growth), providing essential behavioral context beyond the schema.

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 two sentences, front-loaded with purpose and granularity, then return details, use case, and limit. Every sentence earns its place with no filler.

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?

Since there is no output schema, the description explains key return fields and truncation behavior, which is sufficient for an agent. It lacks precise field names/type structure but provides enough context for decision-making.

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 100% coverage with descriptions for all 5 parameters, so the baseline is 3. The description adds marginal reinforcement of granularity and law breakdown but does not introduce new parameter meaning.

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 'Show' and resource 'LTS issuance trends over time' with granularity, which clearly distinguishes it from sibling tools that focus on breakdowns by city, developer, law, or region.

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 use case 'for housing supply pipeline analysis and market timing,' giving clear context for when to use the tool. However, it does not explicitly reference alternative tools or exclusions, 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.