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

With no annotations, the description discloses the side effect of dropping cached application lists and the consequence that the next query re-reads the portal. It also notes that this is normally unnecessary, adding context. It could mention whether any persistent data is affected, but the cache-focused wording 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 short sentences with no redundant information. It front-loads the action and includes a practical note about necessity.

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 parameters, an output schema, and a simple cache-clearing function, the description fully covers purpose, effect, and usage guidance. Nothing essential is missing.

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 and the schema covers 100% of what is needed. Per the baseline for no-parameter tools, the description adds value by explaining the tool's effect rather than requiring parameter documentation.

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 ('Drop all cached application lists') and its intended effect ('so the next query re-reads the portal'). This distinguishes the tool from siblings by its cache-clearing purpose.

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 'Normally unnecessary -- tools take a refresh flag', which tells the agent when not to use this tool and points to an alternative (refresh flag on other tools). This is explicit 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?

No annotations are present, so the description must fully disclose behavioral traits. It states the output (totals) but does not mention whether the tool triggers network requests, whether the 'refresh' parameter causes side effects, or any authentication/staleness considerations. This is a significant gap for an agent deciding whether to invoke it.

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, front-loaded sentence that efficiently conveys the core purpose and context. No word is superfluous, and the em dash effectively separates the output from its domain.

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 output schema exists and likely documents return values, but the description omits essential context about the refresh parameter and any behavioral side effects. Given there are no annotations, the tool's complete behavior is not adequately specified for an agent to safely and correctly invoke it.

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 only parameter, 'refresh', is a boolean with a default of false, but the schema provides no description and the tool description does not mention it at all. The agent receives no guidance on when setting refresh to true is appropriate or what it does. Since schema coverage is 0% and the description fails to compensate, parameter semantics are completely unaddressed.

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 specifies the tool's output as aggregate totals (registered/disposed/pending) for RTI requests and first appeals, and identifies it as the View History dashboard summary. This distinguishes it from sibling tools like rti_list or rti_search by focusing on dashboard totals rather than itemized lists. The absence of an explicit action verb (e.g., 'get') slightly reduces clarity but the intent remains 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 no explicit when-to-use guidance or alternatives. It implies a dashboard context but does not contrast with sibling tools (e.g., rti_list, rti_status) or state when not to use it. This leaves the agent to infer the tool's role relative to others.

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 burden of behavioral disclosure. It lists the informational content returned but does not mention side effects, cache/refresh behavior, or any prerequisites. The refresh parameter implies possible cache clearing or re-fetching, which is not disclosed.

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: the first states the tool's scope and contents, the second provides a clear alternative. Every word earns its place 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?

With an output schema present, return values are already documented. The description effectively covers purpose, usage, and a key alternative, but leaves a gap around the refresh parameter and any session prerequisites (e.g., rti_set_session_url). This prevents a perfect score.

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 explains registration_number by context ('by registration number') but entirely ignores the refresh parameter. The agent receives no guidance on what refresh does or when to set 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 the tool's function: retrieving full filed details of a single RTI application by registration number. It enumerates the specific content returned and explicitly differentiates from rti_status, making it distinct from 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?

Provides explicit guidance on when to use this tool versus an alternative: 'Use rti_status instead if you only need the current state.' This gives clear when-to-use and when-not-to-use direction.

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 tool's behavior: fetching specific document types, saving to disk, returning the saved path, and defaulting to the server's documents folder. It lacks details on error handling or prerequisites like session setup, but for a download tool this is adequate 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 two sentences, front-loaded with the core purpose, and every sentence adds value. It explains the two kinds, the return value, and the default path without any redundancy or 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?

Given the tool's moderate complexity (3 optional parameters, no annotations), the description covers the main behaviors and edge condition for 'reply'. However, it does not mention session prerequisites (sibling tools like rti_session_status suggest a session is needed) or what happens if the application is not found or the download fails. With an output schema present, return values are adequately covered, but the description could be more complete regarding prerequisites and failure modes.

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 explains the 'kind' parameter with two valid values and their meanings, and implies the 'path' parameter via the default folder note. The 'registration_number' is not explicitly described but is inferable from 'an application's PDF'. This provides meaningful semantics beyond the bare 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 clearly states 'Download an application's PDF to disk' with a specific verb and resource. It distinguishes from sibling tools like rti_list (listing) and rti_details (viewing details) by focusing on downloading PDFs, and further differentiates between 'reply' and 'request' document types.

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 each 'kind' value, including the condition that 'reply' only works on disposed applications. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of an explicit when/when-not statement.

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 full responsibility for revealing behavioral traits. It states the export action but does not mention side effects, whether it writes a file to disk or returns data, authentication requirements, or how the 'refresh' parameter affects behavior. This is a significant gap for a tool with no annotation coverage.

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, tightly worded sentence that immediately conveys the core purpose. It avoids redundancy and every phrase adds value, with no filler or unnecessary detail.

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?

While the output schema exists (so return values are covered) and the description is concise, the tool has two parameters with no explanation, and there is no behavioral or usage guidance. In the context of complex RTI tools, this description leaves too many gaps for an agent to invoke it 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?

Schema description coverage is 0%, and the description provides no explanation of the 'path' and 'refresh' parameters. While it lists the CSV fields, that does not clarify parameter meaning. Since the description fails to compensate for the absent schema descriptions, parameter semantics are virtually nonexistent.

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: exporting every RTI request and appeal to a CSV file. It specifies the output format (CSV), the scope (all requests and appeals), and the included fields, which distinguishes it from sibling tools like rti_list or rti_details that likely return data in-app rather than as a file.

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 'for tracking or analysis' implies a use case, but there's no explicit guidance on when to use this tool over alternatives like rti_list or rti_download, nor are there any exclusions or conditions stated. The context is clear enough but lacks explicit differentiation.

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 behavioral burden. It adds meaningful details: results are newest-first as the portal returns them, both date formats are accepted, and status semantics are explained. It does not mention auth or pagination, but these are less critical for a list operation and output schema covers return shape.

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 deliver essential information without redundancy. The first sentence immediately states the primary action, and the second packs search/filter behaviors efficiently.

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 output schema covers return values, and the description provides enough about filtering and ordering for a list tool. A slight gap exists: no explicit guidance on when to use this versus rti_search, and refresh is not described. Overall, it's well within the viable range.

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 compensates by explaining category values, status values, and search fields in detail. It does not explicitly explain limit, offset, or refresh, but these are common and have defaults in 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 ('List') and clear resource ('RTI applications in one bucket'), and the category/status filters distinguish it from sibling tools like rti_search and rti_dashboard. The scope is 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 clear filtering context (category, status, search fields) and even clarifies date formats and result ordering. However, it does not explicitly contrast with alternatives such as rti_search or state when this tool should not be used.

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 results are returned 'oldest first with the number of days elapsed,' which is useful. However, it does not explain the effect of the `refresh` parameter or any caching behavior, which is a significant gap for a tool that likely fetches data. It also does not mention whether the tool is read-only (though 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?

The description is two sentences, front-loaded with the main action, then adds context and a practical use case. Every sentence earns its place, with no fluff or redundancy. It is concise yet informative.

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 the core functionality, legal context, and return behavior, but it fails to mention the `refresh` and `category` parameters, which are essential for understanding the tool's full capability. Given that an output schema exists, return values need not be detailed, but parameter semantics are left incomplete. The tool is moderately complex, so these gaps impact completeness.

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 explains `days` (defaults to 30 and serves as the overdue threshold). However, it does not explain `refresh` or `category`, leaving these parameters ambiguous. This is a major omission since the description is the only source of 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 clearly states the tool's function: 'Pending RTI requests whose reply is overdue.' This distinguishes it from sibling tools like rti_list or rti_search, which do not focus on overdue filtering. The specific reference to the RTI Act's 30-day reply window further clarifies the tool's purpose.

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 a concrete use case: 'use it to decide which applications are ripe for a first appeal.' It explains the default threshold (30 days) and implies that this tool is for identifying overdue requests, distinguishing it from general listing tools. It lacks an explicit 'when not to use' but gives sufficient context for appropriate invocation.

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 behavioral burden. It does disclose matching behavior (fragment matching, two date formats), but it omits important operational details such as what the `refresh` parameter does, whether results are cached, any rate/limit behavior, or side effects. The description is partially transparent but insufficient for a no-annotation 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?

Two sentences, dense with useful information, no filler. The first sentence defines the scope and search keys; the second gives practical usage guidance. Every phrase earns its place.

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 an output schema and moderate complexity, the description covers query semantics and usage context well. However, it omits the meaning of `refresh` and `limit`, and there are no annotations to explain safety or side effects. For an agent to make full use of the tool, more context is needed, so this is below the minimum viable threshold.

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 explains what can go in `query` (registration number fragment, public-authority code, status text, dates), but it says nothing about `limit` or `refresh` parameters. This is a clear gap for an agent trying to invoke the tool correctly.

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 action: 'Search every RTI request and appeal by registration number fragment, public-authority code, status text, filing date or status date.' It names the resource (RTI requests/appeals) and specifies the search dimensions, distinguishing it from sibling tools that likely perform specific lookups or list operations.

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 tells when to use this tool: 'Use this when the user names an application loosely (e.g. 'the BSNL one', 'NIMHANS') or asks what moved on a given day.' This gives clear context, but it does not mention when not to use it or name alternatives, so it stops 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 of behavioral disclosure. It describes what the tool does (checks, shows) and adds context about account and cache staleness, implying a read-only operation. It doesn't explicitly state 'no side effects,' but the wording sufficiently indicates a diagnostic 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 two sentences: the first states functionality, the second gives actionable usage guidance. It's concise, front-loaded, and contains 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?

For a status diagnostic tool with no parameters and an output schema, the description fully covers purpose, usage context, and what the tool reports. The presence of the output schema obviates the need to explain return values.

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 the schema trivially covers everything. Per the rubric, 0 params yields a baseline of 4, and the description doesn't need to add parameter 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 checks the stored RTI Online session URL validity, shows account ownership, and indicates cache staleness, which distinctly separates it from sibling tools like rti_status or rti_dashboard. The verb 'Check' plus specific resources makes 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?

Explicit usage guidance is provided: 'Run this first when other tools report authentication problems.' This tells the agent exactly when to use the tool, even though it doesn't mention alternatives, the 'when' is clearly specified.

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 full responsibility for disclosing behavior. It explicitly mentions two side effects: 'replacing any previous one and clearing cached data.' This gives the agent critical information about the destructive nature of the operation, though it does not mention rate limits or other potential side effects.

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 compact: two sentences, with the first covering the action and the second providing usage context. Every word contributes, with no redundant or vague phrases.

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 parameter, output schema present), the description covers the essential context: purpose, replacement/cache behavior, when to use, and where the URL comes from. The output schema handles return values, so nothing critical is missing.

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 a bare 'url' string with no description (0% coverage). The description compensates by explaining the source of the value: 'copies the full address-bar URL' from the user's browser. This adds meaningful context that the schema lacks.

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: 'Store a new RTI Online View History session URL' with specific actions 'replacing any previous one and clearing cached data.' It distinguishes itself from siblings by focusing on setting the session URL, which is unique among the listed 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 provides a clear scenario for use: 'Use when the old URL stops working' followed by the exact user steps. It does not explicitly mention alternatives or exclusions, but the 'when' context is strong enough to guide an AI agent.

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 transparency. It discloses what the tool returns (state, date changed, remarks/reply summary, PDF availability), which is useful. However, it does not mention side effects or behaviors such as whether a refresh triggers a new external request, whether data is cached, or any rate limits. This is a moderate level of disclosure for a simple status query.

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 a concrete example, followed by the return value details and a colloquial framing. Every clause earns its place, with no fluff or repetition. This is exemplary conciseness.

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-record status lookup, the description covers the essential purpose, input example, and output content. An output schema exists, so return values don't need further explanation. The only notable omission is the behavior of the refresh parameter, which could affect correct invocation. Overall, it is quite 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?

Schema description coverage is 0%, so the description must compensate. It provides an explicit example format for registration_number ('NIMNS/R/E/26/00220'), which adds real semantic value. However, the refresh boolean parameter is entirely unaddressed in both the schema and the description, leaving its purpose and effect ambiguous. The description partially compensates but has 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's function: retrieving the current status of one RTI application by registration number. It specifies the exact resource (one RTI application) and the action (status lookup), and includes an example format. This distinguishes it from sibling tools like rti_list and rti_search, which operate on multiple applications or different 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?

The description provides clear context that this is the everyday 'what happened to my RTI' lookup for a single application, which implies usage when a specific registration number is known. However, it does not explicitly mention alternatives like rti_details or rti_search, nor does it state when not to use this tool, so it lacks explicit exclusions.

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