agent-reasoning-mcp

Overview Schema Source Related Servers Discussions Admin

manage_intentions

Queue, dispatch, track, cancel, or resolve behavior directives for behavior-mcp runtime execution. Use it for immediate runtime behavior instructions, not abstract goal management.

Instructions

Queue, dispatch, track, cancel, or resolve behavior directives for behavior-mcp runtime execution (actions: create, dispatch, get, list, cancel, resolve). Use manage_intentions instead of set_goal when dispatching immediate execution instructions to runtime behaviors rather than managing abstract objectives.

Returns intention record, dispatch status, wire contract payload, or intention list.

Input Schema

TableJSON Schema

Name	Required	Description
`action`	Yes	Intention operation: create, dispatch, get, list, cancel, resolve
`result`	No	Outcome payload for resolve action
`status`	No	Status filter or update
`goal_id`	No	Linked goal ID
`project`	No	Target project slug
`priority`	No	Execution priority (0.0 to 1.0)
`trace_id`	No	Linked decision trace ID
`parameters`	No	Runtime behavior parameters
`deadline_at`	No	ISO-8601 completion deadline
`intention_id`	No	Intention ID for dispatch/get/cancel/resolve
`behavior_name`	No	Target behavior tree name (e.g. "combat_kite", "gather_loop")
`abort_conditions`	No	Auto-abort trigger conditions
`client_request_id`	No	Idempotency key

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.1Oct 1, 2026

changedInput schema / properties / action / description

Previous value: -"Intention operation"New value: +"Intention operation: create, dispatch, get, list, cancel, resolve"

addedInput schema / properties / action / enum

Added value: +[
+  "create",
+  "dispatch",
+  "get",
+  "list",
+  "cancel",
+  "resolve"
+]

Changed22 schema fields changedv0.2.1Sep 24, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / abort_conditions / description
```
Added value: +"Auto-abort trigger conditions"
```
- removedInput schema / properties / abort_conditions / items / additionalProperties
```
Removed value: -true
```
- removedInput schema / properties / abort_conditions / items / properties
```
Removed value: -{}
```
- addedInput schema / properties / action / description
```
Added value: +"Intention operation"
```
- removedInput schema / properties / action / enum
```
Removed value: -[
-  "create",
-  "dispatch",
-  "get",
-  "list",
-  "cancel",
-  "resolve"
-]
```
- addedInput schema / properties / behavior_name / description
```
Added value: +"Target behavior tree name (e.g. \"combat_kite\", \"gather_loop\")"
```
- addedInput schema / properties / client_request_id / description
```
Added value: +"Idempotency key"
```
- addedInput schema / properties / deadline_at / description
```
Added value: +"ISO-8601 completion deadline"
```
- addedInput schema / properties / goal_id / description
```
Added value: +"Linked goal ID"
```
- addedInput schema / properties / intention_id / description
```
Added value: +"Intention ID for dispatch/get/cancel/resolve"
```
- removedInput schema / properties / parameters / additionalProperties
```
Removed value: -true
```
- addedInput schema / properties / parameters / description
```
Added value: +"Runtime behavior parameters"
```
- removedInput schema / properties / parameters / properties
```
Removed value: -{}
```
- addedInput schema / properties / priority / description
```
Added value: +"Execution priority (0.0 to 1.0)"
```
- addedInput schema / properties / project / description
```
Added value: +"Target project slug"
```
- removedInput schema / properties / result / additionalProperties
```
Removed value: -true
```
- addedInput schema / properties / result / description
```
Added value: +"Outcome payload for resolve action"
```
- removedInput schema / properties / result / properties
```
Removed value: -{}
```
- addedInput schema / properties / status / description
```
Added value: +"Status filter or update"
```
- addedInput schema / properties / trace_id / description
```
Added value: +"Linked decision trace ID"
```
First observedv0.1.2Sep 10, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the agent knows this is a non-destructive, non-idempotent mutation surface. The description adds the multi-action nature and the return categories, but does not disclose side effects of cancel/resolve, permission needs, or why the operation is non-idempotent despite having a client_request_id idempotency key.

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

Conciseness4/5

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

Front-loaded with the action verbs and resource, followed by the routing rule and the return-value summary. Tight and well-ordered, with only slight redundancy between the action list in prose and the enum in the schema.

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 13-parameter multi-action tool with nested objects and no output schema, the description covers purpose, routing, and return categories, and the fully-described schema fills in the per-action parameter requirements. Minor gap: it does not map which parameters apply to which action (e.g., intention_id for dispatch/get/cancel/resolve).

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented in the schema; the description adds no per-parameter meaning beyond what is structured. Baseline 3 is appropriate when the schema carries the semantics.

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 specific verbs (queue, dispatch, track, cancel, resolve) applied to a clear resource (behavior directives / intentions) and enumerates the six actions. It explicitly distinguishes itself from the sibling set_goal, so an agent can tell the two apart without opening either schema.

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?

Names the alternative tool (set_goal) and the exact condition that selects this one instead: dispatching immediate execution instructions to runtime behaviors vs. managing abstract objectives. This is explicit when-to-use and when-not-to-use guidance.

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

Deploy Server

manage_intentions

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools