Determine if a research session has enough evidence to finalize by verifying hit counts and attempts per source, ensuring complete prior-art research.
Skontroluje, či má research session dosť dôkazov na finalizáciu.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | ||
| session_id | Yes | ||
| min_total_hits | No | ||
| max_attempts_per_source | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.9.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool 'checks' a condition, which implies a read-only operation, but it does not disclose what the outcome looks like, whether thresholds like min_total_hits affect the result, or whether any state changes occur.
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 direct sentence with no filler or repetition. It front-loads the action and condition, making it very easy to parse, though it is also short enough that the lack of operational detail is noticeable.
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 no annotations, 0% parameter description coverage, and four parameters, this one-line description is under-specified for safe invocation. An output schema exists, so omitting return-value details is acceptable, but the description still leaves the agent guessing about usage conditions, parameter meaning, and side effects.
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 adds no parameter-level detail. The word 'dosť dôkazov' loosely relates to min_total_hits, but run_id, session_id, min_total_hits, and max_attempts_per_source are not explained in the description. Property names and defaults in the schema do some work, but the description does not compensate for the missing schema descriptions.
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 ('Skontroluje'), a specific resource ('research session'), and the condition being checked ('dosť dôkazov na finalizáciu'). This is clear enough for an agent to know the tool is a verification gate rather than an evidence-adding action, even though it does not explicitly name a sibling alternative.
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 the tool is used to decide whether a research session can be finalized, but it does not explicitly state when to call it versus alternatives such as research_session_understand_query or the evidence_to_session tools. There is no when-not-to-use guidance or named alternative, so the agent must infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.