freedom-mcp

Get command center items

get_command_center_items

Read-onlyIdempotent

List Command Center cards for the company (pending by default; pass status_filter for approved/denied/snoozed/all). Returns decisions AND first-class update/report cards (Call minutes, reports) — they are pinned onto the pending page and counted in type_counts. Pass q= to find a named title (e.g. "call minutes") across rank/limit. Pass holdco_class=true for the holdco-chair sweep (class evidence, not one dead run). Also: source agent, priority, age, task type, approval_status, available_actions, resolution_progress, holdco_class, content PREVIEW only — use get_command_center_item with an id for full content. Pending mode ranks most-actionable first and names featured; other status filters (including 'all') are chronological oldest-first unless q= is set (then newest matches).

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Case-insensitive title search (min 2 chars). Use when the operator names a card ("call minutes", a company). Finds update/report cards that ranking would otherwise bury.
`limit`	No	Max items to return (default: 25)
`companyId`	Yes	FreedomOS company id to act within (you must be a member). Required for company-scoped tools.
`task_type`	No	Optional type filter (update, report, decision, alert, …). Use when they ask only for minutes or only for decisions.
`holdco_class`	No	When true, only cards flagged as holdco-visible class evidence (this is a class, these are its instance ids). The holdco chair sweep uses this so class evidence is not read as one dead run.
`status_filter`	No	Filter by status. Default: "pending". Options: pending, approved, denied, snoozed, all

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 23, 2026

addedInput schema / properties / holdco_class

Added value: +{
+  "description": "When true, only cards flagged as holdco-visible class evidence (this is a class, these are its instance ids). The holdco chair sweep uses this so class evidence is not read as one dead run.",
+  "type": "boolean"
+}

Changed2 schema fields changedAug 17, 2026

addedInput schema / properties / q

Added value: +{
+  "description": "Case-insensitive title search (min 2 chars). Use when the operator names a card (\"call minutes\", a company). Finds update/report cards that ranking would otherwise bury.",
+  "type": "string"
+}

addedInput schema / properties / task_type

Added value: +{
+  "description": "Optional type filter (update, report, decision, alert, …). Use when they ask only for minutes or only for decisions.",
+  "type": "string"
+}

First observedJul 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark it read-only and idempotent; the description adds non-obvious behavior: included update/report cards are pinned and counted, ranking differs by status filter, content is preview-only, and q searches across rank/limit. No annotation contradiction exists.

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?

The description is dense and every sentence carries useful information, with the core purpose front-loaded. It is a single long paragraph, so scannability is slightly reduced, but there is no fluff.

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 read-only list tool with no output schema, it describes the returned card types, key fields, preview limitation, default behavior, and ordering semantics. An agent can call it correctly without needing outside knowledge beyond domain terminology.

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. The description adds extra meaning by explaining q's purpose, the default and ordering behavior of status_filter, and holdco_class's role in the holdco chair sweep.

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 'List Command Center cards for the company' and immediately scopes default status, included card types, and key fields. It clearly differentiates from the sibling get_command_center_item by saying content is preview-only and that tool should be used for full content.

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?

Provides explicit conditional guidance: use status_filter for statuses, q for named titles, holdco_class for the holdco-chair sweep, and get_command_center_item for full content. This is more than enough to route an agent to the correct behavior or sibling tool.

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

All freedom-mcp tools Inspect

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

Need Help?