Existing exact HLS request ID only: read-only lifecycle lookup. It does not create or modify a request/order or authorize payment. For long-running or manual work, check status or wait rather than creating another request. Returns only bounded public state, question, quote/payment instruction, fulfillment/shipping update, and next action; it does not list or search requests.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and succeeds: it declares read-only semantics, no creation/modification/authorization, bounded return state, and the specific fields returned. It also conveys that it won't list or search and should be used to avoid duplicate request creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and side-effect profile, then adds usage guidance and return boundaries. Every sentence earns its place and there is no redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup with no output schema, the description is complete: it covers when to use it, what it returns, what it does not do, and how to avoid duplicate requests. The only minor omission is explicit error/not-found behavior, which is not essential for calling this 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 only parameter has no schema description, but the tool description compensates by specifying that request_id must be an existing exact HLS request ID rather than a search/filter term. The exact format is still left to the schema's pattern, which 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 opens with 'Existing exact HLS request ID only: read-only lifecycle lookup,' which names a specific verb ('lookup'), resource ('HLS request' by exact ID), and scope (read-only). It further distinguishes itself from the sibling 'request' tool by explicitly denying creation/modification, payment authorization, and list/search behavior.
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 clearly states this is for existing exact IDs and offers situational guidance: for long-running or manual work, check status or wait rather than creating another request. It does not explicitly name the sibling tool as the alternative for creation or searching, so the when-not guidance is strong but the alternative routing is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two tools have entirely separate roles: request creates a new HLS request, while status is explicitly a read-only lookup for an existing request ID and does not create or modify anything. An agent is unlikely to confuse creating with checking status.
Both tool names are single lowercase words and stylistically consistent, though they do not follow a strict verb_noun pattern. 'request' is action-oriented while 'status' is state-oriented, but the pairing remains readable and predictable.
Two tools is at the thin end of the range; it is plausible for a narrowly focused human-in-the-loop helper, but the server feels minimal and relies heavily on external human interaction rather than offering a richer tool surface.
The server covers create and read-only status, which is a working core workflow, but it lacks update/cancel or any tool for responding to questions or payment instructions that status may surface. That leaves notable lifecycle gaps and possible dead ends for an agent.