agent-reasoning-mcp

Overview Schema Source Related Servers Discussions Admin

set_goal

Create, update, decompose, inspect, or abandon hierarchical goals and task DAGs to formulate multi-step objectives, track sub-goal progress, and list goals.

Instructions

Register, update, decompose, inspect, or abandon hierarchical goals and task DAGs (actions: create, update, decompose, get, list, abandon). Use set_goal instead of manage_intentions when formulating multi-step objectives and sub-goal DAGs rather than queueing concrete execution directives.

Returns goal record, sub-goal hierarchy, completion progress, or goal lists.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Goal ID (required for update, get, abandon)
`limit`	No	Max items to return for list action
`title`	No	Goal title or objective summary
`action`	Yes	The goal management operation to perform: create, update, decompose, get, list, abandon
`status`	No	Goal status
`project`	No	Target project slug
`priority`	No	Goal priority (0.0 to 1.0)
`progress`	No	Completion progress (0.0 to 1.0)
`subgoals`	No	Array of sub-goals for decompose action
`parent_id`	No	Parent goal ID for hierarchical sub-goals
`deadline_at`	No	ISO-8601 deadline timestamp
`description`	No	Detailed goal description
`utility_weights`	No	Goal-specific utility weight overrides
`success_criteria`	No	List of verifiable conditions
`client_request_id`	No	Idempotency key to prevent duplicate creation

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.1Oct 1, 2026

changedInput schema / properties / action / description

Previous value: -"The goal management operation to perform"New value: +"The goal management operation to perform: create, update, decompose, get, list, abandon"

addedInput schema / properties / action / enum

Added value: +[
+  "create",
+  "update",
+  "decompose",
+  "get",
+  "list",
+  "abandon"
+]

Changed21 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 / action / description
```
Added value: +"The goal management operation to perform"
```
- removedInput schema / properties / action / enum
```
Removed value: -[
-  "create",
-  "update",
-  "decompose",
-  "get",
-  "list",
-  "abandon"
-]
```
- addedInput schema / properties / client_request_id / description
```
Added value: +"Idempotency key to prevent duplicate creation"
```
- addedInput schema / properties / deadline_at / description
```
Added value: +"ISO-8601 deadline timestamp"
```
- addedInput schema / properties / description / description
```
Added value: +"Detailed goal description"
```
- addedInput schema / properties / id / description
```
Added value: +"Goal ID (required for update, get, abandon)"
```
- addedInput schema / properties / limit / description
```
Added value: +"Max items to return for list action"
```
- addedInput schema / properties / parent_id / description
```
Added value: +"Parent goal ID for hierarchical sub-goals"
```
- addedInput schema / properties / priority / description
```
Added value: +"Goal priority (0.0 to 1.0)"
```
- addedInput schema / properties / progress / description
```
Added value: +"Completion progress (0.0 to 1.0)"
```
- addedInput schema / properties / project / description
```
Added value: +"Target project slug"
```
- addedInput schema / properties / status / description
```
Added value: +"Goal status"
```
- addedInput schema / properties / subgoals / description
```
Added value: +"Array of sub-goals for decompose action"
```
- removedInput schema / properties / subgoals / items / additionalProperties
```
Removed value: -true
```
- addedInput schema / properties / success_criteria / description
```
Added value: +"List of verifiable conditions"
```
- addedInput schema / properties / title / description
```
Added value: +"Goal title or objective summary"
```
- removedInput schema / properties / utility_weights / additionalProperties
```
Removed value: -true
```
- addedInput schema / properties / utility_weights / description
```
Added value: +"Goal-specific utility weight overrides"
```
- removedInput schema / properties / utility_weights / properties
```
Removed value: -{}
```
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 already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the mutation profile is covered. The description adds an enumeration of return shapes (goal record, sub-goal hierarchy, progress, lists), which is useful since there is no output schema, but it says nothing about permissions, whether 'abandon' is reversible, or side effects of decompose. It adds some context but not rich behavioral disclosure.

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?

The description is front-loaded with the action set and the sibling routing rule, then closes with a brief returns sentence. It is appropriately sized for a multi-action tool, with no filler, though the opening verb list is slightly dense.

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 15-parameter, nested-object, no-output-schema tool, the description covers the action space, sibling routing, and return shapes, which is most of what an agent needs. It stops short of per-action parameter guidance (e.g. which fields apply to decompose vs update), leaving a modest gap.

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 one of the 15 parameters is already documented, including which actions require `id` and the action enum. The description only restates the action names and does not enrich parameter meaning beyond the schema, so the baseline 3 applies.

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 names a specific resource (hierarchical goals and task DAGs) and enumerates the exact verb set (create, update, decompose, get, list, abandon), so an agent knows precisely what the tool does. It also distinguishes itself from the sibling manage_intentions, making it identifiable without opening a 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?

It gives an explicit routing rule: use set_goal rather than manage_intentions 'when formulating multi-step objectives and sub-goal DAGs rather than queueing concrete execution directives.' The alternative and the condition that selects it are both stated.

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

Deploy Server

set_goal

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools