Skip to main content
Glama

Ziel setzen oder Geldziel vorschlagen

create_business_goal

Create an additional goal on explicit request. First check every active get_business_goals page: overlapping goals are not merged or replaced. Use update_business_goal to change a goal and archive_business_goal to retire it.

Translate the requested target

Choose metric, targetValue and cadence together. “20 bookings each week” uses bookings/20/weekly; “20 bookings by the deadline” uses once for the entire inclusive UTC-day span. Weekly repeats the full target in each Europe/Berlin reporting week, even a clipped first/last week; do not divide or prorate it. Resolve ambiguous dates or cadence before creating.

The target’s units follow the metric. A display title or segment label cannot establish missing measurement coverage. Select only an existing, evidenced segment rather than inventing one from the wording.

Check the outcome

Non-money goals become active. Paid revenue instead returns owner_approval_required/activates=false with proposalId/nextAction for a human Owner card; models never confirm. rejected changes nothing—read its reason. A stored definition is not measured progress, and creation spends nothing or triggers a provider action.

Use a fresh requestKey for each new intent across this actor/workspace’s goal create/update/archive operations. Replay returns its old receipt; keyless legacy calls are non-idempotent. After uncertainty read stored goals instead of creating again. Requires operator:prepare, accounting:read, operations:read and current authority.

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": {
      "metric": "<metric>",
      "targetValue": "<targetValue>",
      "startsOn": "<startsOn>",
      "deadlineOn": "<deadlineOn>"
    },
    "name": "create_business_goal"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNoOptional display label; omitted derives a label from the goal. A label does not change measurement or source coverage.
metricYesMeasurement: original paid revenue, inquiry count, booking count or booking rate. Money goals require Owner approval.
cadenceNoonce targets the entire date span; weekly repeats the full targetValue per business reporting week in that span. Omitted means once.once
startsOnYesFirst included valid UTC calendar day, YYYY-MM-DD.
comparatorNoMinimum to reach or maximum to stay within; omitted means at_least.at_least
deadlineOnYesLast included valid UTC calendar day, YYYY-MM-DD, on or after startsOn. Clarify ambiguous dates before a write.
requestKeyNoCaller-generated request UUID. Keep it with the same exact operation, actor and payload; a reused key with changed contents is rejected. After an uncertain result read the goal, never invent another key.
segmentKeyNoExisting segment identifier; omitted or null means tenant-wide. An invented identifier does not establish measurable source coverage.
targetValueYesSafe integer in EUR cents for paid_revenue, counts for inquiries/bookings, or basis points for booking_rate (100 = 1%; maximum 10000). No currency conversion.
segmentLabelNoDisplay label for segmentKey; omitted or null when no segment is selected. Not a source selector.

Output Schema

NameRequiredDescriptionDefault
goalNoFlat stored goal definition and identity/revision metadata; no measured actual, progress or pace.
goalIdNoStored goal identity, present with active/archived results.
reasonNoRejection reason; no goal change was applied.
statusYesRead before reporting success: stored active/archived goal, unactivated Owner request, or rejected change.
replayedNoOriginal receipt replay, not proof of current goal or request state.
revisionNoRevision of the returned active/archived goal, not a measured-progress revision.
activatesYesTrue only for an active non-money result; an Owner request never activates the goal.
nextActionNoExact existing card/read continuation for an unactivated Owner request; models never confirm.
proposalIdNoStored Owner-request identity, present with owner_approval_required; not a goal ID.
presentationNoThe request receipt is retained even if its card could not be displayed. Read the same proposal; never prepare again.
lifecycleStatusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past annotations: non-money goals become active immediately while paid_revenue returns owner_approval_required/activates=false with proposalId for a human Owner, models never confirm, and rejected changes nothing. It also discloses idempotency mechanics (fresh requestKey per intent, replay returns the old receipt, keyless legacy calls are non-idempotent) and the required scopes (operator:prepare, accounting:read, operations:read, current authority), which the annotation set does not convey.

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 core action and alternatives before the hedge-heavy sections, and the headed sections (Translate, Check the outcome) make it scannable for a complex tool. Some clauses are dense and mildly redundant ("A stored definition is not measured progress"), but length is justified by the tool's complexity.

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 an output schema, the description covers the approval-vs-active split, failure semantics, idempotency and recovery after uncertainty, auth requirements, and date/cadence translation. Nothing an agent needs in order to call it correctly or interpret the response appears missing.

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 coverage is 100%, so the schema already documents each field; the description nonetheless adds interpretation rules the schema lacks, such as choosing metric/targetValue/cadence together, working examples ("20 bookings each week" vs "by the deadline"), no proration of clipped reporting weeks, and that segmentLabel/title cannot establish measurement coverage. It stops short of documenting every parameter, but the added semantics over schema are substantive.

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 an additional goal") plus the gating condition ("on explicit request"), and explicitly distinguishes itself from update_business_goal and archive_business_goal by name. An agent can tell this apart from every sibling in the create/update/archive trio 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?

Gives when-to-use (explicit request only), a prerequisite workflow ("First check every active get_business_goals page"), explicit alternatives for different intents (update_business_goal, archive_business_goal), and an exclusion (overlapping goals are not merged or replaced). It also says to resolve ambiguous dates/cadence before writing rather than guessing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources