NEXUS AGI

Update goal

update_goal

DestructiveIdempotent

Edit an existing goal's definition or progress. Only the fields you pass change; fields you pass replace the stored value entirely (lists are not merged). At least one field is required.

To change the plan's steps, resubmit the plan with submit_goal_plan
instead.

Args:
    goal_id: UUID of the goal.
    progress: New progress value in [0.0, 1.0].
    description: New description.
    priority: New priority on a 1-10 scale; stored as priority_weight
        0.0-1.0 (priority=8 is returned as priority_weight 0.8).
    name: New name.
    success_conditions: Replaces the goal's done-criteria
        (target_state.conditions), which is what new plans are generated
        against. Example: {"test_coverage": ">=0.9",
        "description": "concrete, verifiable criterion"}.
    success_metric: How success is measured and evaluated. Set a numeric
        target and operator to use report_goal_measurement. Example:
        {"metric": "test_coverage", "target": 0.9, "operator": ">="}.
    constraints: List of constraints. Stored for reference only; NEXUS
        does not enforce them.
    linked_entities: List of entity UUIDs linked to the goal.
    time_horizon: Free-text time horizon, e.g. 'Q4 2026' or '2 weeks'.

Input Schema

Name	Required	Description	Default
`name`	No
`goal_id`	Yes
`priority`	No
`progress`	No
`constraints`	No
`description`	No
`time_horizon`	No
`success_metric`	No
`linked_entities`	No
`success_conditions`	No

Output Schema

Name	Required	Description	Default
`id`	No
`name`	No
`status`	No
`progress`	No
`goal_type`	No
`created_at`	No
`updated_at`	No
`description`	No
`parent_goal_id`	No
`priority_weight`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Adds context well beyond the annotations: replace-not-merge semantics ('fields you pass replace the stored value entirely'), that constraints are 'stored for reference only; NEXUS does not enforce them', and that success_conditions drives future plan generation. The destructive/idempotent hints are corroborated rather than contradicted, and the priority→priority_weight normalization is disclosed.

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-loads the two behavioral rules (partial update, at-least-one-field) and the sibling routing before the Args list. The length is justified by ten parameters, though a couple of Args lines (name, description) are thin relative to the verbose ones.

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 ten-parameter update tool with nested objects and an output schema present (so return values need not be explained), the description covers mutation semantics, field-level behavior, alternatives, and validation constraints. Nothing required to invoke it correctly appears to be missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does so: all ten parameters are documented with types, ranges, and examples. It clarifies non-obvious mappings (priority 1-10 stored as 0.0-1.0 weight, success_metric requires a numeric target+operator to use report_goal_measurement) that the bare schema cannot convey.

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 precise verb+resource ('Edit an existing goal's definition or progress') and immediately scopes what is editable. It distinguishes itself from the relevant sibling by explicitly routing plan-step changes to submit_goal_plan, so an agent can tell it apart without opening another 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?

Gives an explicit when-not with a named alternative ('To change the plan's steps, resubmit the plan with submit_goal_plan instead') and states the cardinality constraint ('At least one field is required'). This is exactly the routing and precondition information an agent needs.

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

All NEXUS AGI tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?