TRAECNclaw MCP

Send TraeCN Task

traecn_send_message

Submit one coding instruction to TraeCN as durable background work and get a stable taskId immediately; track that task for progress and results instead of sending follow-ups.

Instructions

Submit one user instruction to TraeCN as durable background work and return its stable taskId immediately; the gateway owns queueing, retries, recovery, and result persistence. Use this for every delegated coding request, optionally targeting an existing conversation via conversationId. Do not send follow-up messages to probe progress — track the returned task instead.

Input Schema

Name	Required	Description	Default
`message`	Yes	The exact instruction to execute.
`conversationId`	No	Stable identifier returned by traecn_list_conversations.

Output Schema

Name	Required	Description
`ok`	No	False when the gateway rejected the submission.
`code`	No	Stable machine-readable result or error code.
`error`	No	Original task error on replay, or submission rejection diagnostic.
`result`	No	Original captured result on a terminal replay.
`status`	No	Accepted for new work, or the original terminal status on an idempotent replay.
`taskId`	No	Stable identifier used by traecn_get_task and traecn_cancel_task.
`changed`	No	Whether visible TraeCN state changed.
`message`	No	Human-readable outcome summary.
`success`	No	Whether the operation succeeded.
`terminal`	No	True when returning the original terminal task without submitting again.
`retryable`	No	Whether retrying the same call can succeed later.
`nextAction`	No	Suggested next step after a failure.
`conversationId`	No	Stable TraeCN conversation identifier.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.7.1-glama.1Nov 7, 2026

changedOutput schema / description

Previous value: -"Accepted task identity, or the gateway rejection with reason."New value: +"Accepted task identity, original terminal replay, or gateway rejection with reason."

changedOutput schema / properties / error / description

Previous value: -"Error identifier or diagnostic when the operation failed."New value: +"Original task error on replay, or submission rejection diagnostic."

changedOutput schema / properties / error / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

addedOutput schema / properties / result

Added value: +{
+  "description": "Original captured result on a terminal replay.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / properties / status / description

Previous value: -"Acceptance status reported by the gateway."New value: +"Accepted for new work, or the original terminal status on an idempotent replay."

changedOutput schema / properties / status / enum

Previous value: -[
-  "accepted"
-]New value: +[
+  "accepted",
+  "done",
+  "error",
+  "cancelled",
+  "queue_timeout",
+  "review_rejected"
+]

addedOutput schema / properties / terminal

Added value: +{
+  "description": "True when returning the original terminal task without submitting again.",
+  "type": "boolean"
+}

First observedAug 24, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Beyond the annotations (readOnly=false, openWorld=true, idempotent=false, destructive=false), the description discloses that work is asynchronous/durable, that the gateway owns queueing, retries, recovery, and persistence, and that a taskId comes back immediately. It stops short of stating that each call creates a distinct task (relevant given idempotentHint=false) or any auth/rate-limit expectations, so it is strong but not exhaustive.

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?

Two tightly written sentences, with the core action and return value front-loaded, followed by the usage rule and the anti-pattern. No filler or redundancy.

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

Completeness5/5

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

For a two-parameter tool with full schema description coverage and an output schema, this is complete: the async contract, the return of taskId, and the correct follow-up behavior are all covered. Nothing needed to call it correctly is missing.

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. The description adds real meaning: conversationId 'optionally' targets an existing conversation, implying that omitting it starts fresh work, and message is framed as the single instruction being delegated. That is a genuine semantic contribution over the schema's own field descriptions.

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?

The description opens with a concrete verb+resource+outcome: 'Submit one user instruction to TraeCN as durable background work and return its stable taskId immediately.' It clearly delineates this from siblings like traecn_get_task (tracking) and traecn_cancel_task (aborting), so an agent can pick the right tool without reading schemas.

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?

It gives explicit when-to-use ('Use this for every delegated coding request'), an optional targeting condition ('optionally targeting an existing conversation via conversationId'), and an explicit when-not-to ('Do not send follow-up messages to probe progress — track the returned task instead'), which routes the agent to the tracking sibling.

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