Aimgod

Add a goal

add_goal

Add one goal to the month, quarter or year that contains date (today when omitted), optionally with subgoals, a star and the goals it comes after. Horizon defaults to month. For a whole path to a bigger goal, build_goal_flow fits instead.

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": {
      "text": "<text>"
    },
    "name": "add_goal"
  }
}

Input Schema

Name	Required	Description
`date`	No	YYYY-MM-DD
`text`	Yes
`after`	No	Ids of goals to reach before this one, from any period (a month goal may lead to a year goal)
`sphere`	No	Goals sphere name (case-insensitive) or id
`horizon`	No
`subgoals`	No
`important`	No	The star

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedInput schema / properties / after / description

Previous value: -"Ids of goals in the same period to reach before this one"New value: +"Ids of goals to reach before this one, from any period (a month goal may lead to a year goal)"

Changed3 schema fields changedOct 7, 2026

addedInput schema / properties / after

Added value: +{
+  "description": "Ids of goals in the same period to reach before this one",
+  "items": {
+    "format": "uuid",
+    "type": "string"
+  },
+  "maxItems": 8,
+  "type": "array"
+}

addedInput schema / properties / important

Added value: +{
+  "description": "The star",
+  "type": "boolean"
+}

addedInput schema / properties / subgoals

Added value: +{
+  "items": {
+    "maxLength": 500,
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

First observedOct 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), so the safety baseline is covered. The description contributes real behavioral information beyond that: the horizon defaults to month and the date defaults to today, plus that subgoals, a star, and predecessor goals are all optional. It stops short of saying what a duplicate or conflicting goal does or what is returned.

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 sentences, no filler: the core action and its temporal scoping come first, the sibling redirect comes last. Every clause carries information an agent would otherwise have to infer.

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

Completeness3/5

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

For a 7-parameter mutation tool with no output schema, the definition never says what comes back (the new goal's id would matter since 'after' takes ids) and omits the collection limits (max 8 predecessors, 10 subgoals, 1000-char text). What it does cover is accurate, but an agent would be guessing about the response.

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?

With schema coverage at 57%, the description compensates by stating defaults the schema does not encode for horizon ("defaults to month") and date ("today when omitted"), and by framing "after" as goals to reach before this one. It never mentions the sphere parameter, which the schema must carry alone, and adds little on text.

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?

Starts with a specific verb and resource ("Add one goal") and scopes it to the month/quarter/year containing a date. It explicitly separates itself from build_goal_flow, so an agent can pick between the two without opening either schema, and it is clearly distinct from add_task/add_subtask siblings.

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?

Gives the when-not directly: "For a whole path to a bigger goal, build_goal_flow fits instead." It also supplies the default selection conditions (date = today when omitted, horizon = month), which is exactly the routing context an agent needs before calling.

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.