Skip to main content
Glama
talonicdev

talonic-mcp

Official
by talonicdev
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

Submit Agent Task

talonic_submit_agent_task

Submits declared output fields for a claimed agent task, validates them transactionally, and resumes the parked document once processing is complete.

Instructions

Submit declared output fields for a claimed Agent-stage task and resume the parked document.

USE WHEN: processing is complete and every required output in output_contract is ready. NOT FOR: undeclared fields or partial lease maintenance (use talonic_heartbeat_agent_task). ARGS: task_id, execution_epoch, outputs keyed exactly by declared field key, and optional summary. The platform validates all fields and types transactionally before writing anything.

Input Schema

NameRequiredDescriptionDefault
outputsYesOutput field key to { value, confidence?, reasoning?, escalate?, quote?, document_id? }. Use only declared fields.
summaryNoOptional result summary, up to 4,000 characters.
task_idYesAgent task UUID.
execution_epochYesExecution epoch returned by the successful claim. Stale epochs are rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.90
    • addedInput schema / properties / outputs / additionalProperties / properties / document_id
      Added value: +{
+  "description": "The contract document (anchor or candidate supplier) the quote comes from.",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}
    • addedInput schema / properties / outputs / additionalProperties / properties / escalate
      Added value: +{
+  "description": "Agentic Review (product) tasks only: hand this field to a human instead of writing it. value is shown as the proposal, reasoning as the reason.",
+  "type": "boolean"
+}
    • addedInput schema / properties / outputs / additionalProperties / properties / quote
      Added value: +{
+  "description": "Verbatim evidence for a changed value, copied from document_id. Required when the task's autonomy sets requireQuote; an unverified change is escalated, not written.",
+  "maxLength": 4000,
+  "type": "string"
+}
    • changedInput schema / properties / outputs / description
      Previous value: -"Output field key to { value, confidence?, reasoning? }. Use only declared fields."New value: +"Output field key to { value, confidence?, reasoning?, escalate?, quote?, document_id? }. Use only declared fields."
  2. Addedv0.1.75

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only state readOnly=false/destructive=false, so the description carries most of the burden and does add real value: transactional all-or-nothing validation before writing, and the parked-document resume transition. It stops short of describing rejection/failure behavior (e.g. whether the lease survives a validation failure) beyond what the schema already covers for stale epochs and quotes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly labeled blocks (statement, USE WHEN/NOT FOR, ARGS) with the state-changing effect front-loaded. Every sentence carries distinct information; nothing is repeated from the schema verbatim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with a nested outputs object, transactional semantics and the resume effect are covered. There is no output schema, yet the description does not indicate what a successful submission returns (e.g. updated field values or status), which is the one remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds a non-obvious constraint: outputs must be keyed exactly by declared field key. It also names the argument set (task_id, execution_epoch, outputs, optional summary), giving useful orientation ahead of opening the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Submit declared output fields for a claimed Agent-stage task') plus the side effect ('resume the parked document'). It is clearly distinguishable from sibling claim/heartbeat/decision-task tools by naming the Agent-stage task lifecycle and the declared-field contract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit USE WHEN condition (processing complete, every required output in output_contract ready) and explicit NOT FOR exclusions (undeclared fields, partial lease maintenance) with the correct alternative named: talonic_heartbeat_agent_task. No inference required.

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

Deploy Server

Other Tools