MCP WorkBoard CrunchTools

Workboard Create Objective Tool

workboard_create_objective_tool

Create WorkBoard team or individual objectives with optional key results, owners, and target dates. Requires an OAuth Data-Admin token; API cannot update or delete objectives.

Instructions

Create a new objective with optional key results.

Creates Team or Individual objectives. Requires an OAuth token whose account has the Data-Admin role; instant JWT tokens cannot create objectives. The API has no update or delete for objectives — those are UI-only.

Team objectives must be tied to a team: pass team (a team ID from workboard_get_teams_tool). Provide the objective name, owner, dates, and optionally key results with targets. Each key result has a name and optional start_value, target_value, and unit_type (e.g. "Number", "Currency", "Percent").

Input Schema

Name	Required	Description	Default
`name`	Yes	Objective name (e.g. "Increase customer retention")
`team`	No	Team ID (or name) — required for team objectives, ignored for individual
`owner`	Yes	Owner's email address or user ID
`narrative`	No	Optional description/narrative for the objective
`permission`	No	Visibility, comma-separated. Team objectives accept team/report/internal/any; personal objectives accept owner/manager. Defaults by type when omitted (team → "internal,team", individual → "owner").
`start_date`	Yes	Start date in YYYY-MM-DD format
`key_results`	No	Optional list of key results, each with a name and optional start_value, target_value, and unit_type
`target_date`	Yes	Target completion date in YYYY-MM-DD format
`objective_type`	No	"team" (default) or "individual"	team

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.12.0Oct 17, 2026

removedInput schema / properties / goal_type

Removed value: -{
-  "default": "1",
-  "description": "\"1\" for Team objective (default), \"2\" for Personal objective",
-  "type": "string"
-}

changedInput schema / properties / key_results / anyOf

Previous value: -[
-  {
-    "items": {
-      "additionalProperties": {
-        "type": "string"
-      },
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "additionalProperties": false,
+      "description": "A key result to attach to a new objective.\n\nField names use OKR vocabulary; they are mapped to the WorkBoard API's\n``metric_*`` fields when the objective is created.",
+      "properties": {
+        "name": {
+          "description": "Key result name",
+          "maxLength": 255,
+          "minLength": 1,
+          "type": "string"
+        },
+        "start_value": {
+          "anyOf": [
+            {
+              "maxLength": 20,
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "description": "Starting value (e.g. '0')"
+        },
+        "target_value": {
+          "anyOf": [
+            {
+              "maxLength": 20,
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "description": "Target value (e.g. '100')"
+        },
+        "unit_type": {
+          "anyOf": [
+            {
+              "maxLength": 255,
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "description": "Unit type (e.g. 'Number', 'Currency', 'Percent')"
+        }
+      },
+      "required": [
+        "name"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / key_results / description

Previous value: -"Optional list of key result dicts, each with keys like\n         \"metric_name\", \"metric_start\", \"metric_target\", \"metric_type\""New value: +"Optional list of key results, each with a name and optional\n         start_value, target_value, and unit_type"

addedInput schema / properties / objective_type

Added value: +{
+  "default": "team",
+  "description": "\"team\" (default) or \"individual\"",
+  "type": "string"
+}

addedInput schema / properties / permission / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / permission / default
```
Previous value: -"internal,team"New value: +null
```

changedInput schema / properties / permission / description

Previous value: -"Visibility setting (default \"internal,team\")"New value: +"Visibility, comma-separated. Team objectives accept\n        team/report/internal/any; personal objectives accept\n        owner/manager. Defaults by type when omitted (team →\n        \"internal,team\", individual → \"owner\")."

removedInput schema / properties / permission / type
```
Removed value: -"string"
```

addedInput schema / properties / team

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Team ID (or name) — required for team objectives, ignored for individual"
+}

Addedv0.7.0May 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

No annotations are supplied, so the description carries the full burden, and it delivers: it discloses the authorization model (Data-Admin role required, instant JWT unsupported) and the lifecycle limitation that created objectives cannot be updated or deleted through the API. Output-schema presence means return values need not be re-described here.

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 with the core action, then prerequisites, then the team constraint, then the key-result shape. Sentences are short and purposeful, though the key-result field list is restated from the schema and the team-objective rule slightly overlaps the `team` parameter description.

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 9-parameter creation tool with an output schema, the description covers auth, variant selection, required team linkage, and key-result composition, which is enough to call it correctly. It stops short of error or partial-failure behavior (e.g. what happens if one key result is invalid), the only notable remaining gap.

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 schema already documents every parameter including permission defaults and date formats; this is the baseline-3 case. The description corroborates the key-result shape (name plus optional start_value, target_value, unit_type with examples) but adds little that the schema does not already state.

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?

Opens with a specific verb+resource ("Create a new objective with optional key results") and immediately scopes the two variants it can produce (Team or Individual). It is clearly distinguishable from the read-side siblings like workboard_get_objectives_tool and workboard_get_objective_details_tool.

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?

States hard prerequisites (OAuth token with Data-Admin role; instant JWT tokens cannot create objectives) and a negative constraint (no update/delete exists via the API, so agents should not search for a create counterpart). It also tells the agent where to source a required input, naming workboard_get_teams_tool for team IDs, and explains the team-vs-individual condition.

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

Deploy Server