Skip to main content
Glama

Add agent activity

add_agent_activity
Destructive

Add ONE activity to an agent's activity plan without regenerating the whole plan. Use to give an agent a new recurring or one-off deliverable. (To rebuild the entire plan, use recalibrate_agent_jd with regenerate_activities=true instead.)

[write-tier — first use may require a manager's approval; a from-now-on approval makes future calls seamless, a just-once approval re-asks next time. Call it on the first clear ask; the card is the yes — do not re-ask in chat.]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
activityYesThe activity to add.
agent_idNoUUID of the agent. Optional if agent_name is provided.
companyIdYesFreedomOS company id to act within (you must be a member). Required for company-scoped tools.
agent_nameNoName of the agent (e.g. "Aiko"). Provide this or agent_id.
linked_kr_idNoRequired when activity is supplied flat. This work needs a goal. Pick the Key Result this loop moves. If none exists, create the Key Result first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / activity / properties / frequency / description
      Previous value: -"How often it runs."New value: +"How often it runs — daily/weekdays/weekly/biweekly/monthly/quarterly auto-run on a cadence (weekdays = once each Mon–Fri in America/Los_Angeles; weekends skip); once/as_needed/on_demand are manual-only (run via trigger_agent_activity). Any other value is rejected so the scheduler can never silently drop the activity."
    • changedInput schema / properties / activity / properties / frequency / enum
      Previous value: -[
      -  "daily",
      -  "weekly",
      -  "biweekly",
      -  "monthly",
      -  "quarterly",
      -  "once",
      -  "as_needed",
      -  "on_demand"
      -]New value: +[
      +  "daily",
      +  "weekdays",
      +  "weekly",
      +  "biweekly",
      +  "monthly",
      +  "quarterly",
      +  "once",
      +  "as_needed",
      +  "on_demand"
      +]
    • changedInput schema / properties / activity / properties / linked_kr_id / description
      Previous value: -"Required. The Key Result this loop moves. This work needs a goal. Pick the Key Result this loop moves."New value: +"Required. The Key Result this loop moves. This work needs a goal. Pick the Key Result this loop moves. If none exists, create the Key Result first."
    • changedInput schema / properties / activity / properties / name / description
      Previous value: -"Short, unique activity name — the stable key the scheduler uses."New value: +"Short, unique activity name — the stable key the scheduler uses. Rejected if a name already exists on this agent (use update_agent_activity to change one)."
    • changedInput schema / properties / linked_kr_id / description
      Previous value: -"Required when activity is supplied flat. This work needs a goal. Pick the Key Result this loop moves."New value: +"Required when activity is supplied flat. This work needs a goal. Pick the Key Result this loop moves. If none exists, create the Key Result first."
  2. Changed3 schema fields changed
    • addedInput schema / properties / activity / properties / linked_kr_id
      Added value: +{
      +  "description": "Required. The Key Result this loop moves. This work needs a goal. Pick the Key Result this loop moves.",
      +  "type": "string"
      +}
    • changedInput schema / properties / activity / required
      Previous value: -[
      -  "name",
      -  "frequency"
      -]New value: +[
      +  "name",
      +  "frequency",
      +  "linked_kr_id"
      +]
    • addedInput schema / properties / linked_kr_id
      Added value: +{
      +  "description": "Required when activity is supplied flat. This work needs a goal. Pick the Key Result this loop moves.",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / activity / properties / max_iterations / description
      Previous value: -"Optional. Per-activity tool-loop iteration budget (clamped 5–30; default 10). Raise for read-heavy deploy-class activities."New value: +"Optional. Per-activity tool-loop iteration budget (clamped 5–30; default 15, higher for multi-tool plans). Raise for read-heavy deploy-class activities."
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Adds meaningful behavioral context beyond annotations by explaining the write-tier approval behavior, the from-now-on vs just-once distinction, and the 'card is the yes' rule. It does not directly elaborate on destructiveHint=true, but it also does not contradict the annotation because adding to a live plan can still alter schedule state.

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?

The description is tightly written and front-loaded: the core action and scope come first, the alternative comes second, and the approval instruction earns its place. There is no filler or repetition of schema content.

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 nested-object mutation tool with no output schema, the description plus schema covers selection, parameters, scope, and permission behavior well. A brief statement about the expected result or returned confirmation would fully close the loop, but nothing essential is missing for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the detailed parameter documentation carries the semantic burden. The description reinforces plan-level intent but does not add per-parameter meaning beyond what the schema already provides, matching the baseline for high coverage.

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: 'Add ONE activity to an agent's activity plan'. It also explicitly distinguishes this from regenerating the whole plan, which separates it clearly from sibling tools like recalibrate_agent_jd and update_agent_activity.

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 direct usage guidance: use it to add a new recurring or one-off deliverable, and names the exact alternative (recalibrate_agent_jd with regenerate_activities=true) for rebuilding the plan. The approval note also tells the agent when to call and not to re-ask, making the invocation protocol explicit.

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