LTS MCP Server

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

Discloses grouping by city+province to avoid name collision, row cap of 25k, and truncated flag. No annotations provided, so description carries burden; but does not explicitly state read-only nature, which is implied.

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 concise sentences: purpose, use cases, constraints. Front-loaded with verb and resource, no unnecessary words.

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?

Covers grouping, row cap, truncated flag, and use cases. Lacks output format details but no output schema exists; cross-reference partially compensates. Adequate for a query 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 coverage is 100%, so baseline 3. Description adds no extra meaning to parameters beyond what schema already provides (law, year, limit, 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?

Description clearly states 'Rank cities by LTS count' with detailed breakdown (province, region, law, etc.), distinguishing it from siblings like lts_by_developer 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?

Explicitly mentions use cases (housing pressure indices, market analysis, hotspots) and provides cross-reference to PSGC MCP. Also notes row cap and truncated flag check for filtering.

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 the 25k row cap, the need to check the truncated flag, and suggests narrowing filters. This provides essential behavioral info for a read tool, though sorting order is implicit.

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, front-loading the core purpose, then use cases, then behavioral notes. Every sentence adds value with no 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 no output schema and 4 optional parameters, the description covers the main behavior (ranking, breakdowns, cap). The 'active/expired split' is mentioned but not detailed, which is a minor gap.

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%, so baseline is 3. The description does not elaborate on individual parameters beyond what the schema provides, nor does it add novel context for the parameters.

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 ranks developers by LTS count with regional footprint, law breakdown, and active/expired split. This is distinct from sibling tools like lts_by_city or lts_by_law, making its 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 provides specific use cases (developer intelligence, competitive analysis, identifying dominant developers) and advises checking the truncated flag and narrowing filters when capped. It lacks explicit when-not-to-use instructions but gives adequate context.

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, description discloses cap at 25k rows and truncated flag, plus behavior change when no year filter. Provides context beyond schema, but could mention response structure or data freshness.

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, no fluff, front-loaded with main purpose. Every sentence adds value 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?

Covers key aspects: breakdown by law, regional distribution, YOY shift, data cap, and truncated flag. No output schema, but description sufficiently prepares agent for use.

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 has 100% coverage with descriptions for both params. Description adds value by stating year should be omitted for YOY shift, which is not in schema. Region description is clear but adds no extra beyond 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?

Description clearly states the tool breaks down LTS records by housing law (BP220 vs PD957) and shows regional distribution per law and year-over-year shift. Distinct from siblings like lts_by_region which only filters 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?

Explicitly says 'Use for housing policy analysis and socialized housing supply tracking.' Also explains when to omit year for YOY shift calculation. However, does not explicitly state when not to use or contrast with 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 fully bears the burden. It discloses the 25k row cap, truncated flag behavior, and the types of returned aggregates. No contradictions with structured 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?

Four sentences, each adding value: first sentence states function and outputs, second provides usage context, third offers cross-reference, fourth covers limits. No waste, front-loaded effectively.

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 outlines return values (count, share, breakdowns) and limitations. Provides cross-reference and usage guidance. Could benefit from specifying exact field names or structure, but overall sufficient for an 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?

Schema coverage is 100%, so baseline 3 applies. The description mentions filtering by law and status in the context of breakdown, but the schema already describes each parameter with comparable detail. Minimal added value 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?

Clearly states the tool aggregates LTS records by region, specifies output metrics (count, market share, law breakdown, active/expired split), and distinguishes from siblings like lts_by_city or lts_by_developer which operate on different groupings.

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 (State of RE reports, regional housing analysis) and cross-reference guidance with PSGC MCP. Mentions the 25k row cap and truncated flag for handling limits. Lacks explicit when-not-to-use or comparison to alternative tools.

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?

The description discloses that it returns existence flags and full record details. With no annotations provided, it carries the full burden and adequately describes the output behavior, but could mention error handling for invalid formats.

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 concise sentences: first states purpose, second details output. No redundant information, earnestly 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 lookup tool with one parameter, no output schema, and no nested objects, the description fully covers what the tool does, what it returns, and how it differs from siblings.

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 single parameter 'ltsNumber' is already fully described in the schema (100% coverage). The description does not add additional semantics beyond the schema's description.

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 action ('Check if a specific LTS number exists') and the resource ('in the system'). It specifies the output (existence in two tables and full record details), distinguishing it from sibling tools that query by other criteria 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 implies usage when you have a specific LTS number to verify, and the sibling list suggests alternatives for other query types. However, it does not explicitly state when not to use or provide exclusion criteria.

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?

Discloses sorting behavior, summary counts, row cap (25k), and a truncated flag. With no annotations, the description covers key behavioral traits, though it omits potential side effects or authentication requirements.

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 concise sentences: first states purpose and output format, second suggests use cases, third notes limits and corrective action. No wasted words and front-loaded with key 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?

For a tool with no output schema, it adequately describes return structure (sorted records with days remaining, summary counts). Missing details on exact record structure, but sufficient for an AI agent to understand what to expect.

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 already describes all parameters (100% coverage). Description adds output semantics (summary counts by region and developer) and clarifies that 'days' defines the look-ahead window, enhancing understanding beyond 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?

Describes finding LTS records expiring within a given number of days, sorted by urgency, with summary counts. Explicitly states use cases (compliance monitoring, renewal pipeline, risk assessment), distinguishing it from sibling tools that filter by other criteria.

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 and a cap warning with guidance to narrow filters if truncated. Does not explicitly exclude alternative sibling tools, but the context and purpose clearly differentiate when to use 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?

No annotations are provided, so the description bears full responsibility. It states the tool returns distinct regions and cities, with optional filtering by region. It does not describe side effects, authentication, or rate limits, but for a simple read-only query tool, this level of transparency 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 three sentences long, each serving a distinct purpose: stating the tool's main function, describing the output, and providing usage guidance. There is no redundancy, and the 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?

Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It explains the output ('distinct regions and cities'), the optional filtering, and the context for use. No additional details are 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 input schema has 100% description coverage for the single parameter 'region.' The description reiterates the schema's meaning ('Optionally filter cities by region') but does not add additional semantic detail beyond what the schema already provides. Baseline of 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 clearly states the tool's purpose: 'Get available filter values for LTS queries. Returns distinct regions and cities from the verification queue.' It specifies the verb 'Get,' the resource 'filter values,' and the scope 'for LTS queries,' differentiating it from sibling tools like lts_queue or lts_search that perform queries.

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 before calling lts_queue or lts_search with region/city filters to get valid values.' It specifies when to use the tool and mentions the related tools, but does not explicitly state when not to use it or list alternatives beyond the mentioned ones.

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 full behavioral burden. It discloses that it returns computed fields (is_expired, days_until_expiry), summary counts, and the primary LTS number. It also mentions fuzzy matching for the name parameter. This is fairly transparent for a read-only tool, though authorization needs are not mentioned.

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 a single, well-structured sentence that conveys all key information upfront. Every clause serves a purpose: what the tool returns, how to call it (two parameter options), and additional context (fuzzy matching). No unnecessary words.

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 two parameters and no output schema, the description is complete. It details the return value (computed fields, summaries, primary number) and the two input methods. The absence of an output schema is compensated by the description's specificity about what is returned.

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?

Both parameters are already described in the schema (100% coverage). The description adds significant value: it explains the priority order (projectId takes precedence) and the fuzzy lookup behavior for projectName. It also clarifies the return type—'complete LTS picture'—which goes beyond 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 clearly states the tool retrieves 'the complete LTS picture for a single project' with specific computed fields and summaries. It distinguishes itself from sibling tools like lts_records (which likely lists multiple) by emphasizing 'single project' and 'primary LTS number'.

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 says to pass either a project UUID or a project name (fuzzy matched), and notes that projectId takes priority. While it doesn't explicitly list when not to use this tool vs alternatives, the 'single project' scope implies it's for individual project queries, not bulk or filtered searches.

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 implies a read-only browse operation but does not explicitly state that there are no side effects, nor does it disclose permissions, rate limits, or data mutability. This is inadequate for complete 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 concise with three sentences: first states purpose, second lists filters, third gives specific usage. It is front-loaded and free of fluff, though a bit more structure (e.g., bullet points) could 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 moderate complexity with 9 parameters and no output schema, the description adequately explains the core functionality and key filters. It covers browsing, normalization, confidence levels, and expiring items. Pagination details are covered in the schema. Some differentiation from siblings is implicit but not explicit.

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% description coverage, so each parameter is documented. The description adds value by grouping filters and explaining the expiringWithinDays parameter beyond the schema. This enhances understanding without redundancy.

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 browses LTS records with filters, specifying the verb 'Browse' and resource 'LTS records'. It distinguishes from sibling tools by listing specific filters like confidence, linked status, region, and text search, which are not collectively present in the siblings.

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 guidance on when to use filters such as 'Filter by confidence' and 'Use expiringWithinDays to find records expiring soon'. However, it does not explicitly state when not to use this tool versus its siblings like lts_by_region or lts_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?

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions that results come from both lts_records and published projects, but lacks details on ordering, case sensitivity, or result structure. This is adequate but not rich.

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 concise, two sentences with no wasted words. It front-loads the core action and scope, making it 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 description explains that results come from two sources and serves as a universal entry point, but without an output schema, it does not describe the result format or pagination behavior. For a tool with 3 parameters, this is adequate but not fully complete.

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 clear descriptions for each parameter. The tool description does not add meaning beyond the schema; it merely reiterates the search criteria. 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 clearly states that the tool searches across DHSUD LTS records and published projects by various criteria, positioning it as a universal entry point. However, it does not explicitly distinguish it from specialized sibling tools like lts_by_city or lts_by_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 implies broad use as a universal entry point but provides no explicit guidance on when to use this tool versus alternatives. Given the existence of specialized siblings, the description should mention that for specific filters, dedicated tools may be more appropriate.

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 details the return structure (two sections with lists) but does not disclose any behavioral traits like authentication needs, performance characteristics, or idempotency. For a read-only tool with no parameters, this is adequate but not comprehensive.

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 consists of two sentences, both front-loaded with key information. No wasted words; every clause adds 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?

Given no output schema, the description adequately explains the two sections. However, it does not mention format (e.g., JSON), potential empty results, or performance implications. Slightly incomplete for a comprehensive understanding.

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 no properties, so schema description coverage is 100%. The description adds no parameter information because there are none, but baseline for 0 params is 4. No additional value needed.

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 system-wide LTS statistics' and enumerates the two sections with specific metrics. It distinguishes from sibling tools like lts_by_city or lts_by_developer, which focus on filtered views.

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 for overall stats but does not explicitly state when to use this tool versus siblings or provide when-not-to-use guidance. Alternatives exist but are not 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?

No annotations are provided, so the description carries full burden. It discloses a 25k row cap and advises checking the truncated flag, which is a notable behavioral constraint. It also outlines return values. It lacks explicit statements about side effects or permissions, but given the read-only nature implied, 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 three sentences, front-loading the main purpose and key details. Every sentence adds value: purpose, return values, use case, and a constraint. No wasted words.

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 return values (counts, law breakdown, peak period, growth percentage) and a constraint (capped rows). It covers the essential functionality for a trend-analysis tool with 5 optional parameters.

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 descriptions for each parameter. The description adds context about the output (e.g., law breakdown) but does not enhance parameter meaning beyond what the schema already provides, so 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 clearly states the tool shows 'LTS issuance trends over time' with granularity options, and specifies what it returns (period counts, law breakdown, peak period, YoY growth). This distinguishes it from siblings like lts_by_city or lts_by_region, which focus on other 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 explicitly says 'Use for housing supply pipeline analysis and market timing,' providing a clear use case. However, it does not mention when not to use it or suggest alternative sibling tools for other purposes.

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