Skip to main content
Glama

projects

Read and update a team's objective board: track goals, key results, owners, stages, progress, budgets, and which work pays into each result.

Instructions

Projects | the caller's OWN project board with its objectives and key results, read and written deterministically (no LLM on this path): what a team agreed to achieve, what it works on, who works on it, how far along it is, and which key result each piece of work pays into. Call it for "what is my team working on", "which key result has no project behind it", "what does marketing contribute", "which projects are off track", "what is undecided", or to add or move a project, objective or key result.

PROJECTS: "list" folds the board on ONE axis, group = okr (default) | country | function | person. On person a project appears under its owner and every contributor; on the other axes once. Nothing set on the axis lands in a NAMED group ("No country set"), never dropped. Undecided projects come back in inbox. "get" returns one project with milestones and KPIs; "create" adds one; "update" changes one (stage, progress, traffic light, dates, parent, budget, effort, impact, key_result_id). A project carries a target date (due sentence derived on read), a parent (three levels at most), prerequisites (blocked_by), a budget in its own currency (never converted), effort in days and impact 1 to 5; sort = effort_impact orders by impact then effort without a score.

OBJECTIVES: "objectives" returns every objective with its key results: value, source (dataset or manual), a DERIVED status (on track, at risk, off track, no data yet; from baseline, target, direction and time left, never set by hand, and no value is never on track), guardrails, target history and the projects behind it. "create_objective" needs title; "update_objective" needs id; "create_key_result" needs objective_id, title, target (or country_values); "update_key_result" needs id. Changing a target needs target_reason (ten characters or more) and is kept in a history nothing rewrites. A key result may carry values per country (country_values) and says how they add up (aggregation); with country values its target and current are DERIVED from them (sum, average, or none = no total, country_total says how many countries reported) and a typed target is ignored, and with country_column a dataset-bound key result reads value_column once per country. A key result with guards_id is a GUARDRAIL: breached, the guarded key result is off track even at full attainment.

THE VALUE RULE for KPIs and key results: EITHER a typed number OR read live from a column of any dataset on this account, such as a Google Search Console, Shopify or World Bank table or an uploaded CSV (dataset_id + value_column, optionally filter_column + filter_value), never both. A value that cannot be read is null with a reason, never zero.

NEVER: it never derives the traffic light or progress of a project (a person sets both), never invents a key result (link one of the account key results by key_result_id; list returns them as key_results), and never reaches another account: a foreign id answers not found. On a shared board a member with the editor role is a project lead: the board admin decides which fields a lead may change, and a refused field answers 403 naming it. Requires the caller's own autario account (API key or OAuth).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe id of the thing to read or change: the project for "get" and "update", the objective for "update_objective", the key result for "update_key_result".
kindNoIs this a project with an end, or recurring day-to-day work? Default "project".
sortNoFor "list": the order of cards inside each group. "board" (default) puts off-track work first; "effort_impact" orders by impact (5 to 1) then effort (fewest days first), unrated work last. No combined score is computed.
unitNoFor key results: the unit the number is in.
briefNoA short description of what the project is.
groupNoFor "list": which axis the cards are folded on. Default "okr", which is the axis that answers "does everything we do pay into something we agreed".
ownerNoThe one person accountable for it.
stageNoWhere it stands. A new project starts "active" (running); when the board owner switched on "New projects need admin approval", a non-admin's new project starts at "inbox" (pending review) and only an admin moves it out. "long_list" = agreed, not started; "done" = finished.
titleNoProject title. Required for "create".
actionNoWhat to do. Default "list".
formatNoOutput wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
impactNoExpected impact as a judgement: 1 low, 2 some, 3 clear, 4 high, 5 very high.
statusNoThe traffic light, set by a person: on track, at risk, off track.
targetNoFor key results: the number that counts as done. Required on create.
countryNoThe region or country that runs it, in the account's own words ("DACH", "Nordics"), not an ISO code.
ends_onNoFor objectives: end of that window, YYYY-MM-DD.
baselineNoFor key results: where the number started. Attainment runs from baseline to target.
functionNoThe function that contributes it ("Marketing", "Supply chain").
directionNoFor key results: whether higher or lower is better. Default increase.
guards_idNoFor key results: makes this key result a GUARDRAIL of that key result.
parent_idNoThe project this one is part of. Projects nest at most three levels deep (programme, workstream, piece); a move that would make a fourth level or a loop is refused with a sentence. Parent progress, when the parent has none of its own, is the mean of its children and says so.
starts_onNoFor objectives: start of the window its key results are paced against, YYYY-MM-DD.
commitmentNoFor objectives: committed (expected at 1.0) or aspirational (0.7 is a good outcome). Changes the status rule of its key results, never a number.
dataset_idNoFor key results: the dataset the value is read from (any dataset on this account).
started_atNoStart date, YYYY-MM-DD.
aggregationNoFor key results: how its countries add up to a region. sum (default) for counts and money, average for rates and levels, none lists the countries without a total.
effort_daysNoEstimated effort in person days.
target_dateNoTarget date, YYYY-MM-DD. "Due in N days" / "overdue by N days" is derived from it on every read and never stored.
contributorsNoEveryone else working on it. These names are what the person axis groups by, together with the owner.
filter_valueNoFor key results: the value filter_column must have.
manual_valueNoFor key results: the current value typed by hand. Shown as typed by hand; prefer dataset_id + value_column.
objective_idNoFor "create_key_result": the objective it belongs to. "objectives" lists them.
progress_pctNoProgress in percent, 0 to 100, set by a person. Never derived from milestones or dates.
spent_amountNoMoney spent so far, typed by a person, in budget_currency.
value_columnNoFor key results: the column of dataset_id that holds the number.
budget_amountNoBudget. Needs budget_currency. Never converted between currencies.
filter_columnNoFor key results: optional column to filter the dataset on.
key_result_idNoThe id of the key result this project pays into. "list" returns the linkable ones in `key_results`; pass one of their `id` values. Omit for work that pays into nothing yet, which is exactly what the OKR axis is there to make visible.
resources_urlNoA link to where the actual work lives (a drive folder, a board, a doc). http(s) only.
target_reasonNoFor "update_key_result": why the target moves (ten characters or more). Required whenever `target` changes; the change is kept in the key result history.
country_columnNoFor key results with dataset_id: the column that names the country of a row (autario_entity when the dataset has it). value_column is then read per country; a country the dataset lacks keeps its typed value.
country_valuesNoFor key results: the value per country, [{ country, current, target }]; country as a name or ISO code. A region total uses these; several countries without values are never split.
guardrail_noteNoFor key results: how this number could be reached the wrong way.
budget_currencyNoThree letter currency code of the budget, e.g. EUR.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.21.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) are consistent and minimal, and the description adds substantial behavior: what is derived vs. person-set (traffic light and progress are never derived, key result status is DERIVED), the value rule (typed number XOR dataset column, null-with-reason on failure), the NEVER section including cross-account isolation and 403 on refused fields, and the auth requirement (caller's own autario account).

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?

Purpose and actions are front-loaded, and the sectioned PROJECTS / OBJECTIVES / VALUE RULE / NEVER layout is coherent. It is dense and long with heavy capitalization, but given 44 parameters and 9 actions most sentences carry load; it stops short of being padded.

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-action, 44-parameter mutation tool with no output schema, the description covers derived fields, error behavior, auth and guardrail logic well. It does not describe the shape of returned data or pagination, which is a mild gap but not blocking given the format parameter and detailed field semantics.

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 baseline is 3, but the description adds cross-parameter interactions the schema cannot express: country_values makes the target/current derived and ignores a typed target, aggregation governs how countries total up, and the parent/progress relationship. These go beyond the per-parameter schema text.

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?

The opening states a specific resource (the caller's OWN project board with objectives and key results) and the operations available (list/get/create/update/objectives/key results), and it enumerates recognizable verbs of use ("what is my team working on", "which projects are off track"). No sibling tool touches projects or OKRs, so the scope is unambiguous.

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?

The description gives explicit trigger phrasings for the read path and names each write action (create/update a project, objective or key result) with the condition that selects it. It also states prerequisites (create_objective needs title, update_key_result needs id, target changes need target_reason), which is exactly the when-to-use guidance an agent needs.

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