Aimgod

Build a goal flow

build_goal_flow

Create a bigger goal and the path to it in one step, on the Goals canvas of a month, quarter or year (month and today when omitted). A good flow: exactly one final goal (final: true, the result, no subgoals) that nothing comes after; 3 to 6 measurable milestones before it ("Send 20 proposals", not "Work harder"), each with 2 to 4 concrete subgoals; parallel branches add up to the final goal. after lists what comes first. Cards are placed left to right. Max 14 goals. A year chain (horizon year): a month goal per month (own horizon and date, up to 3 subgoals), linked earlier month first, the year goal last; a month may rest.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "goals": "<goals>"
    },
    "name": "build_goal_flow"
  }
}

Input Schema

Name	Required	Description
`date`	No	YYYY-MM-DD
`goals`	Yes
`horizon`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 29, 2026

changedInput schema / properties / goals / items / properties / after / description

Previous value: -"Keys in this flow or ids of goals already in this period"New value: +"Keys in this flow or ids of the user's existing goals (any period)"

addedInput schema / properties / goals / items / properties / date

Added value: +{
+  "description": "A day inside this goal's own period, e.g. 2027-03-01 for March 2027",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

addedInput schema / properties / goals / items / properties / horizon

Added value: +{
+  "description": "This goal's own horizon when it differs from the flow's (a month goal in a year chain)",
+  "enum": [
+    "month",
+    "quarter",
+    "year"
+  ],
+  "type": "string"
+}

changedInput schema / properties / goals / maxItems
```
Previous value: -12New value: +14
```

AddedOct 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only declare the generic write profile (readOnly=false, destructive=false, idempotent=false). The description adds real behavior: a hard cap of 14 goals, left-to-right card placement, default horizon/date, 'after' semantics for ordering, and the year-chain shape. It does not say what happens if the flow is invalid or partially applied, which matters for a non-idempotent batch write.

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?

Purpose is front-loaded in the first clause and every subsequent sentence carries a distinct constraint (limits, defaults, ordering, two flow recipes). Some compressed phrasing ('a month may rest', 'linked earlier month first') costs readability but no sentence is filler.

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 non-idempotent batch creation tool with no output schema and a nested 3-parameter payload, the description covers the structural contract, caps, defaults, and cross-references to existing goal ids. It stops short of describing the returned result or failure behavior, which is the 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 description coverage is only 33%, but the description compensates well: 'final: true, the result, no subgoals', 'after lists what comes first', per-goal horizon 'when it differs from the flow's', a month goal with 'up to 3 subgoals', and subgoal phrasing quality. Only 'sphere' and 'important' go unexplained beyond 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 and resource ('Create a bigger goal and the path to it in one step') plus the canvas and horizons it applies to, which distinguishes it from the single-goal sibling add_goal and from link_goals. The defaults for omitted horizon/date are stated inline.

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

Usage Guidelines4/5

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

Gives strong prescription for what a valid request looks like (exactly one final goal, 3-6 measurable milestones, 2-4 subgoals each, parallel branches, max 14 goals) and a whole alternate recipe for the year chain. It never names add_goal/link_goals as the alternative for simpler cases, so the when-not-this-tool guidance is missing.

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

All Aimgod tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.