Submit a new or revised typed research contract to persist the update and queue the task for execution, bypassing RVA review.
Submit a new or revised typed Research Contract without RVA review; the updated contract is persisted and the task is queued for execution.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| research_program | No | ||
| research_contract | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only (write operation) and no idempotency, but description adds that the contract is 'persisted' and the task is 'queued for execution'. This is useful context beyond annotations. However, it doesn't disclose if this overwrites existing contracts, whether it requires existing task state, or any 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?
Description is one sentence, front-loaded with the core action and scope. It clearly states the result (persisted, queued). It adds the key distinction 'without RVA review' upfront. 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 the complexity and nested objects, the description is minimal. It doesn't explain the difference between this and rva_review_next_experiment or how the research_program fits in. With no output schema, it doesn't describe return values or errors. But annotations cover mutation semantics partially, and the schema provides structure. Agent might need more context to select 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%, but the schema itself defines required fields and structure. The description mentions 'typed Research Contract' which implies the research_contract parameter structure, and the task_id is referenced by 'the task'. However, it does not explicitly describe research_program parameter, which is not required but present. Baseline 3 is appropriate as the schema is rich enough.
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 and resource: 'Submit a new or revised typed Research Contract without RVA review'. It clarifies that the contract is persisted and the task is queued. However, it doesn't fully distinguish from sibling tools like rva_review_next_experiment or rva_challenge_result, and the term 'without RVA review' is an important distinguishing trait but not explicitly contrasted with alternatives.
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 submitting a contract without RVA review, but provides no explicit guidance on when to use this versus rva_review_next_experiment or other RVA tools. No exclusions or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.