Skip to main content
Glama

freedom-mcp

by com.getfreedomos
OverviewDiscussionsAdmin

Create key result

create_key_result
Destructive

Add a key result to an objective (the KR in OKR). Key results are measurable outcomes that track progress toward the objective. You can identify the parent objective by title or ID.

[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
unitNoUnit of measurement (e.g., "%", "$", "users", "trees")
monthNoYYYY-MM the current_value belongs to (default: this UTC month). Writes monthly_history. Pass 2026-06 to stamp June, not a Q4 pile.
titleYesKey result title (measurable outcome). Title, unit, and current must name the SAME quantity FO can see.
due_dateNoDue date (YYYY-MM-DD). Strongly recommended — a KR without one cannot expire or alarm.
companyIdYesFreedomOS company id to act within (you must be a member). Required for company-scoped tools.
directionNoGoal direction. "at_least" (default): reach the target. "at_most": stay UNDER the target — a ceiling (e.g. founder decisions per 28 days). A ceiling KR is on-track only while current ≤ target.
assigned_toNoUser ID or "me"/"current_user" to assign to
descriptionNoWhat the number is (e.g. "This month cash in minus cash out"). Agents read this back on get_okrs — do not leave blank for cash KRs.
objective_idNoID of the parent objective (optional if using objective_title)
target_valueNoTarget value to achieve. 0 is a valid floor (breakeven / this month FCF ≥ $0). Omit only if you intend the default 100.
current_valueNoManual KRs only — omit when measure_source is set: the source owns current and the daily OKR health sweep fills it (a typed value on a bound KR is refused). For a manual KR: THIS calendar month's actual, not YTD, not a projection. Cash-flow and Amazon-deposit KRs should bind fcf_last_closed_month / amazon_deposits_last_closed_month instead of typing a number.
measure_sourceNoBind current progress to a live data source so it auto-updates daily instead of relying on manual edits. One of: stripe_active_subscribers, stripe_mrr, crm_active_leads, crm_webhook_leads_month, customer_evidence_count, product_telemetry_count, fcf_last_closed_month, amazon_deposits_last_closed_month, human_door_decisions_28d, factory_landings_aligned_pct_28d. Use when the KR measures exactly what a source provides. Do not bind finance/P&L here.
objective_titleNoTitle of the parent objective (use this or objective_id)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / current_value / description
      Previous value: -"THIS calendar month's actual (default: 0). Not YTD, not a future projection. For FCF use get_financial_summary displayed_net_cash_flow; for Amazon deposits use get_monthly_trends Amazon Sales. Do not invent Amazon GMV. Bind measure_source, or leave 0."New value: +"Manual KRs only — omit when measure_source is set: the source owns current and the daily OKR health sweep fills it (a typed value on a bound KR is refused). For a manual KR: THIS calendar month's actual, not YTD, not a projection. Cash-flow and Amazon-deposit KRs should bind fcf_last_closed_month / amazon_deposits_last_closed_month instead of typing a number."
    • addedInput schema / properties / direction
      Added value: +{
+  "description": "Goal direction. \"at_least\" (default): reach the target. \"at_most\": stay UNDER the target — a ceiling (e.g. founder decisions per 28 days). A ceiling KR is on-track only while current ≤ target.",
+  "enum": [
+    "at_least",
+    "at_most"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / measure_source / description
      Previous value: -"Bind current progress to a live data source so it auto-updates daily instead of relying on manual edits. One of: stripe_active_subscribers (active paying Stripe subscriptions), stripe_mrr ($ MRR), crm_active_leads (active CRM leads). Use when the KR measures exactly what a source provides."New value: +"Bind current progress to a live data source so it auto-updates daily instead of relying on manual edits. One of: stripe_active_subscribers, stripe_mrr, crm_active_leads, crm_webhook_leads_month, customer_evidence_count, product_telemetry_count, fcf_last_closed_month, amazon_deposits_last_closed_month, human_door_decisions_28d, factory_landings_aligned_pct_28d. Use when the KR measures exactly what a source provides. Do not bind finance/P&L here."
  2. Changed5 schema fields changed
    • changedInput schema / properties / current_value / description
      Previous value: -"Current progress value (default: 0). Do not invent a live number for a quantity FO cannot measure (e.g. Amazon GMV). Bind measure_source, or leave 0."New value: +"THIS calendar month's actual (default: 0). Not YTD, not a future projection. For FCF use get_financial_summary displayed_net_cash_flow; for Amazon deposits use get_monthly_trends Amazon Sales. Do not invent Amazon GMV. Bind measure_source, or leave 0."
    • addedInput schema / properties / description
      Added value: +{
+  "description": "What the number is (e.g. \"This month cash in minus cash out\"). Agents read this back on get_okrs — do not leave blank for cash KRs.",
+  "type": "string"
+}
    • addedInput schema / properties / month
      Added value: +{
+  "description": "YYYY-MM the current_value belongs to (default: this UTC month). Writes monthly_history. Pass 2026-06 to stamp June, not a Q4 pile.",
+  "type": "string"
+}
    • changedInput schema / properties / target_value / description
      Previous value: -"Target value to achieve"New value: +"Target value to achieve. 0 is a valid floor (breakeven / this month FCF ≥ $0). Omit only if you intend the default 100."
    • changedInput schema / properties / title / description
      Previous value: -"Key result title (measurable outcome)"New value: +"Key result title (measurable outcome). Title, unit, and current must name the SAME quantity FO can see."
  3. Changed1 schema field changed
    • changedInput schema / properties / current_value / description
      Previous value: -"Current progress value (default: 0)"New value: +"Current progress value (default: 0). Do not invent a live number for a quantity FO cannot measure (e.g. Amazon GMV). Bind measure_source, or leave 0."
  4. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already communicate readOnlyHint=false, idempotentHint=false, and destructiveHint=true. The description adds valuable behavioral context beyond those annotations by explaining the write-tier approval flow, including first-use approval, from-now-on vs just-once approvals, and the instruction not to re-ask in chat. No contradiction with annotations was found.

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 compact and front-loaded: two sentences state the purpose and objective-identification mechanism, and a bracketed approval note carries the operational guidance. There is no filler, and every sentence adds necessary value.

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?

Given the tool has 13 parameters, all fully described by the input schema, and annotations already cover safety properties, the description provides the missing approval-flow context and the core purpose. It lacks an explicit description of the return value, and there is no output schema, but the schema and annotations make the tool callable with sufficient confidence.

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 baseline is 3 and the schema already documents all 13 parameters in detail. The description adds one useful semantic note about identifying the parent objective 'by title or ID,' which maps to objective_id and objective_title, but it does not significantly extend parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action and resource: 'Add a key result to an objective (the KR in OKR).' It also clarifies that key results are measurable outcomes and that the parent objective can be identified by title or ID. However, it does not explicitly differentiate from related siblings like generate_key_results or update_key_result, so it falls just short of full sibling-level distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives actionable invocation guidance in the approval note: 'Call it on the first clear ask; the card is the yes — do not re-ask in chat.' It also implies the tool is used for adding a measurable outcome to an objective. But it does not compare against alternatives or state when not to use this tool, leaving some tool-selection inference to the agent.

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

All freedom-mcp toolsInspect
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