check_task_statusReturns the status of a long-running Lightbringer task identified by a ticket: state (pending, running, succeeded, or failed), progress, and the findings once it has succeeded.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | Yes | The task ticket identifier |
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| result | No | ||
| progress | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the possible states, that progress is included, and that findings only appear once the task has succeeded. It goes beyond the annotation baseline.
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 sentence that front-loads the verb and resource, then packs the key return fields and state enum into a compact list. Every word earns its place, with no repetition 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?
With one parameter, an existing output schema, and annotations covering the read-only/non-destructive nature, the description sufficiently covers what the agent needs to invoke the tool correctly. It even explains the lifecycle aspects (states and when findings appear), making it fully self-contained.
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%, and the only parameter 'ticket' is already described as 'The task ticket identifier'. The tool description repeats this concept but adds no additional semantic detail, such as the ticket format or how to obtain it. The high schema coverage justifies the baseline score of 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 states a specific verb ('Returns') and a specific resource ('status of a long-running Lightbringer task identified by a ticket'), and enumerates the exact fields returned (state, progress, findings). This clearly differentiates it from sibling tools that deal with inventions, reviews, and comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: after initiating a long-running task, to poll its status via the ticket. It doesn't explicitly name alternatives or exclusions, but none are apparent among the sibling tools, which are about different resource types. The context is clear enough without explicit exclusions.
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.
Most invention lifecycle tools are clearly distinct, but there are overlapping pairs: add_comment and reply_to_comment both handle replies to threads, and fetch overlaps with get_invention for invention content. These overlaps require careful reading of descriptions to select the right tool.
Tool names generally follow a snake_case verb_noun pattern like list_inventions, create_invention, and update_invention. A few deviations such as fetch, search, and whoami break the pattern slightly, but the naming remains predictable overall.
At 18 tools, the set is slightly above the ideal scoped range and contains some functional overlap, making it feel heavier than necessary. Each tool has a plausible purpose, but the surface could be tightened by merging the overlapping comment and document-retrieval tools.
The tool set covers the core invention lifecycle well: create, get, list, update, validate, submit, and analyze, plus review and comment workflows. Minor gaps exist around comment management and lack of explicit review creation/deletion, but there are no major dead ends for common workflows.