finance

Goals: Create goal plan

create_goal_plan

    Create a goal PLAN on Visions & Goals — the qualitative
    clarify-and-plan side (SMART criteria, action steps). Suited to a
    vague aspiration that needs shaping ("I want to get fit", "someday
    buy a cabin"). The money-tracking side is a separate zoninga goal;
    the two can be linked.

    Args:
        title: The goal statement (required, ≤300 chars).
        description: Longer context for the plan.
        timeframe: One of "short", "medium", "long" (default medium).
        target_date: YYYY-MM-DD (optional).
        smart_specific: Answer to the SMART "Specific" prompt (optional).
        smart_measurable: SMART "Measurable" answer (optional).
        smart_achievable: SMART "Achievable" answer (optional).
        smart_relevant: SMART "Relevant" answer (optional).
        smart_timebound: SMART "Time-bound" answer (optional).
        zoninga_goal_id: An existing zoninga goal id to link the new
            plan to (sets that goal's ``vng_goal_id``).

    Returns:
        {"goal": {id, title, ..., edit_url}}. ``edit_url`` is the page
        on Visions & Goals where the plan can be refined.

Input Schema

TableJSON Schema

Name	Required	Default
`title`	Yes
`timeframe`	No	medium
`description`	No
`target_date`	No
`smart_relevant`	No
`smart_specific`	No
`smart_timebound`	No
`zoninga_goal_id`	No
`smart_achievable`	No
`smart_measurable`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations cover the safety profile (non-readonly, non-idempotent, non-destructive, open world), so the bar is lower. The description still adds real behavioral context beyond them: the title length cap, the side effect of setting the linked goal's vng_goal_id, and the returned edit_url.

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 purpose followed by organized Args/Returns sections; the docstring formatting ('<' char cap, backtick field names) adds slight noise but each line carries information. No filler sentences.

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 10-parameter mutation with no output schema, the description documents the return payload (goal id, edit_url) and every parameter's semantics, plus the linkage side effect. Nothing an agent needs to invoke it correctly is 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 coverage is 0%, so the description carries the full burden and does: each of the 10 parameters is explained, including the timeframe enum values ('short','medium','long') that the schema leaves as a bare string and the date format for target_date. This is meaningful meaning beyond the structured fields.

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+resource ('Create a goal PLAN on Visions & Goals') and immediately scopes it to the qualitative clarify-and-plan side, explicitly separating it from the money-tracking 'zoninga goal'. An agent can distinguish it from create_goal without opening the schema.

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 a clear usage condition ('Suited to a vague aspiration that needs shaping') with two concrete examples, and names the alternative domain (the money-tracking side) that is a separate goal. It stops short of explicitly naming the sibling tool to call instead, but the when-to-use guidance is strong.

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

All finance 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.

Resources

Need Help?