freedom-mcp

Agree playbook

agree_playbook

Destructive

Seal a Playbook plan (source_details.plan_agreed_at) so run_playbook can dispatch. Operator door — Chat or MCP. Same seal Focus writes. Structured Plays refuse Run until this exists. Use after get_playbook when the steps look right.

Routing: Agree who does what on a Playbook → use this, then run_playbook

[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

Name	Required	Description
`agreed`	No	Default true. Pass false to clear the seal (required after the plan changes).
`companyId`	Yes	FreedomOS company id to act within (you must be a member). Required for company-scoped tools.
`playbook_id`	No	UUID of the Playbook (use this or playbook_title).
`playbook_title`	No	Title (or fragment) of the Playbook (use this or playbook_id).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 23, 2026

addedInput schema / properties / playbook_id

Added value: +{
+  "description": "UUID of the Playbook (use this or playbook_title).",
+  "type": "string"
+}

addedInput schema / properties / playbook_title

Added value: +{
+  "description": "Title (or fragment) of the Playbook (use this or playbook_id).",
+  "type": "string"
+}

removedInput schema / properties / tactic_id

Removed value: -{
-  "description": "UUID of the Playbook (use this or tactic_title).",
-  "type": "string"
-}

removedInput schema / properties / tactic_title

Removed value: -{
-  "description": "Title (or fragment) of the Playbook (use this or tactic_id).",
-  "type": "string"
-}

AddedAug 27, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already mark destructiveHint=true and readOnlyHint=falseapper, but the description adds valuable behavioral detail: the approval workflow ('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') and an explicit instruction to the agent ('call it on the first clear ask; the card is the yes — do not re-ask in chat'). This goes well beyond the annotations.

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 front-loaded with the core action and consequences. However, it includes some cryptic extras like 'Operator door — Chat or MCP' and 'Same seal Focus writes' that may not be immediately meaningful, and the routing line slightly repeats the first paragraph. Still, each sentence adds useful context.

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?

The description covers the purpose, the prerequisite for run_playbook, the approval flow, and the relationship to get_playbook. Since there is no output schema, return semantics are not required. Minor gaps like clarifying the 'Operator door' phrase mean it's not perfect, but overall it is complete enough for an agent to use correctly.

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?

The schema description coverage is 100%, so all parameters are already fully documented in the schema. The description does not add any additional parameter semantics beyond what is in the schema, so it stays at the baseline 3.

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 description clearly states the action ('Seal a Playbook plan'), the underlying field it sets (source_details.plan_agreed_at), and the consequence (so run_playbook can dispatch). It distinguishes itself from siblings like run_playbook by positioning itself as a prerequisite, and mentions get_playbook as the preceding step.

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?

It explicitly provides when-to-use guidance: 'Use after get_playbook when the steps look right' and a routing rule 'Agree who does what on a Playbook → use this, then run_playbook'. It also notes that Structured Plays refuse Run until this seal exists, which gives a clear precondition.

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?