Skip to main content
Glama

freedom-mcp

by com.getfreedomos
OverviewDiscussionsAdmin

Route operator HUD

route_operator_hud
Destructive

Route the operator's desk HUD to a view they asked to see — open a door (money, sessions, home, roster, loadout, upgrades), lock a company zone, drill into a company's money, fill the pixel well with the focused card's breakdown, focus a SPECIFIC pending card, or go back. UI navigation only: changes what is on screen, never data, never spend. Use when the operator asks to SEE something on their desk HUD ("show me the money", "open sessions", "go back", "show me Conduit") — or signals they are trying to UNDERSTAND the focused item ("break that down for me", "what do you mean"). focus_card puts a SPECIFIC pending card in front of the operator (card_id from your own get_command_center_items read), show_content true also opens its visual — USE THIS when presenting anything for approval: route it into view FIRST, then speak.

[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
verbYesWhat to do on the desk HUD: open_door (needs view) | sessions_global | lock_zone (needs company_id) | unlock | money_company (needs company_id) | well (fills the pixel well with the focused card's breakdown — no args; no-op if nothing is focused) | focus_card (needs card_id; optional show_content; optional company_id) | back | done.
viewNoWhich door to open. Required (and only allowed) when verb=open_door.
card_idNoPending card id (from get_command_center_items) to focus on the operator's desk HUD. Required (and only allowed) when verb=focus_card.
companyIdNoFreedomOS company id to act within (you must be a member). Required for company-scoped tools.
company_idNoCompany (portfolio) id to lock/drill into. Required when verb is lock_zone or money_company; only allowed otherwise when verb=focus_card — pass the card's company_id (from your own card read) so the desk can switch zones to land it.
show_contentNoAlso open the card's visual (the well) in the same move. Only allowed when verb=focus_card.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / company_id / description
      Previous value: -"Company (portfolio) id to lock/drill into. Required (and only allowed) when verb is lock_zone or money_company."New value: +"Company (portfolio) id to lock/drill into. Required when verb is lock_zone or money_company; only allowed otherwise when verb=focus_card — pass the card's company_id (from your own card read) so the desk can switch zones to land it."
    • changedInput schema / properties / verb / description
      Previous value: -"What to do on the desk HUD: open_door (needs view) | sessions_global | lock_zone (needs company_id) | unlock | money_company (needs company_id) | well (fills the pixel well with the focused card's breakdown — no args; no-op if nothing is focused) | focus_card (needs card_id; optional show_content) | back | done."New value: +"What to do on the desk HUD: open_door (needs view) | sessions_global | lock_zone (needs company_id) | unlock | money_company (needs company_id) | well (fills the pixel well with the focused card's breakdown — no args; no-op if nothing is focused) | focus_card (needs card_id; optional show_content; optional company_id) | back | done."
  2. Changed4 schema fields changed
    • addedInput schema / properties / card_id
      Added value: +{
+  "description": "Pending card id (from get_command_center_items) to focus on the operator's desk HUD. Required (and only allowed) when verb=focus_card.",
+  "type": "string"
+}
    • addedInput schema / properties / show_content
      Added value: +{
+  "description": "Also open the card's visual (the well) in the same move. Only allowed when verb=focus_card.",
+  "type": "boolean"
+}
    • changedInput schema / properties / verb / description
      Previous value: -"What to do on the desk HUD: open_door (needs view) | sessions_global | lock_zone (needs company_id) | unlock | money_company (needs company_id) | well (fills the pixel well with the focused card's breakdown — no args; no-op if nothing is focused) | back | done."New value: +"What to do on the desk HUD: open_door (needs view) | sessions_global | lock_zone (needs company_id) | unlock | money_company (needs company_id) | well (fills the pixel well with the focused card's breakdown — no args; no-op if nothing is focused) | focus_card (needs card_id; optional show_content) | back | done."
    • changedInput schema / properties / verb / enum
      Previous value: -[
-  "open_door",
-  "sessions_global",
-  "lock_zone",
-  "unlock",
-  "money_company",
-  "well",
-  "back",
-  "done"
-]New value: +[
+  "open_door",
+  "sessions_global",
+  "lock_zone",
+  "unlock",
+  "money_company",
+  "well",
+  "focus_card",
+  "back",
+  "done"
+]
  3. Changed2 schema fields changed
    • changedInput schema / properties / verb / description
      Previous value: -"What to do on the desk HUD: open_door (needs view) | sessions_global | lock_zone (needs company_id) | unlock | money_company (needs company_id) | back | done."New value: +"What to do on the desk HUD: open_door (needs view) | sessions_global | lock_zone (needs company_id) | unlock | money_company (needs company_id) | well (fills the pixel well with the focused card's breakdown — no args; no-op if nothing is focused) | back | done."
    • changedInput schema / properties / verb / enum
      Previous value: -[
-  "open_door",
-  "sessions_global",
-  "lock_zone",
-  "unlock",
-  "money_company",
-  "back",
-  "done"
-]New value: +[
+  "open_door",
+  "sessions_global",
+  "lock_zone",
+  "unlock",
+  "money_company",
+  "well",
+  "back",
+  "done"
+]
  4. Added

TDQS

A3.6/5.0
Behavior4/5

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

The description adds useful behavioral context beyond annotations: 'UI navigation only: changes what is on screen, never data, never spend' and the write-tier approval behavior. This complements the readOnlyHint=false and destructiveHint=true annotations by clarifying that mutating side effects are UI-level rather than data-level. It does not fully describe what every verb does at the UI level, but the side-effect profile is clear enough.

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 front-loaded, with the core purpose and key usage examples appearing early. The write-tier approval note is useful but compartmentalized in a way that complicates parsing, and the opening sentence is an overloaded run-on. Overall, each section earns its place even if the structure could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers when to use the tool, the approval flow, and the focus_card workflow, which is strong. However, there is no description of return values or response behavior in the absence of an output schema, and the verb/door mismatches leave gaps. The schema covers the parameters well, so the description is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already carries the parameter burden; the description adds some useful context about sourcing card_id from get_command_center_items and using show_content, but it also introduces a misleading door list with 'sessions' and 'loadout' that are not valid view enum values. The description is therefore not a net positive for parameter understanding and could cause incorrect invocation.

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 what the tool does: route the operator's desk HUD to a requested view, with an explicit 'UI navigation only' guard and a list of actions. It differentiates itself from data-reading siblings by saying it 'never data, never spend.' However, the parenthetical door list ('sessions', 'loadout') does not match the schema's view enum ('missions', 'character'), which makes the purpose description slightly unreliable.

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

Usage Guidelines4/5

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

The description gives explicit trigger scenarios with quoted examples such as 'show me the money', 'open sessions', and 'go back', plus a dedicated rule for using focus_card when presenting anything for approval. It also tells the agent to call it on the first clear ask and not re-ask. It does not name a competing alternative tool explicitly, but the when-to-use and when-not-to-use guidance is otherwise strong.

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