Skip to main content
Glama

Take over screens for a while

start_takeover
Destructive

Show something on screens over their normal content, now.

When to use:

  • Existing content for a while (the lunch menu until 2 pm), or a pre-armed emergency.

When NOT to use:

  • A lasting change: use set_screen_content.

What to know:

  • Content ends by itself; an emergency stays above everything until end_takeover, so confirm its scope with the person first. Returns castId for end_takeover. Needs screen.cast.

Parameters:

  • Pass exactly one of: contentId with contentKind (from list_items), or emergencyTemplateId (from list_items kind emergency_templates).

  • scopeKind: all (default, every screen this connection reaches), node with scopeNodeId, or screens with screenIds. An emergency ignores scope and uses its template's.

  • expiresAt: ISO 8601 with offset, default one hour from now.

  • Example: {contentKind:"playlist", contentId:"pl_lunch", scopeKind:"node", scopeNodeId:"on_store12", expiresAt:"2026-10-20T14:00:00-07:00"}.

Input Schema

NameRequiredDescriptionDefault
headlineNoListing name, with contentId only.
contentIdNoContent id.
expiresAtNoEnd time.
scopeKindNoWhich screens.
screenIdsNoScreen ids.
contentKindNoContent kind.
scopeNodeIdNoLocation id.
emergencyTemplateIdNoEmergency template id.

Output Schema

NameRequiredDescriptionDefault
castIdNoPass to end_takeover to stop early (an emergency's id starts with emg_).
expiresAtNoWhen it ends by itself (absent for an emergency).
screenCountNoHow many screens show it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / message
      Removed value: -{
      -  "description": "New announcement.",
      -  "properties": {
      -    "body": {
      -      "description": "Smaller text, up to 400 characters.",
      -      "maxLength": 400,
      -      "type": "string"
      -    },
      -    "headline": {
      -      "description": "Main text, up to 120 characters.",
      -      "maxLength": 120,
      -      "type": "string"
      -    },
      -    "tone": {
      -      "description": "Background style; default announcement.",
      -      "enum": [
      -        "announcement",
      -        "alert",
      -        "celebrate",
      -        "info"
      -      ],
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "headline"
      -  ],
      -  "type": "object"
      -}
  2. Changed1 schema field changed
    • changedInput schema / properties / headline / description
      Previous value: -"Listing name."New value: +"Listing name, with contentId only."
  3. Changed9 schema fields changed
    • changedInput schema / properties / contentId / description
      Previous value: -"Existing content id, from list_items."New value: +"Content id."
    • changedInput schema / properties / contentKind / description
      Previous value: -"With contentId: the kind of content."New value: +"Content kind."
    • changedInput schema / properties / emergencyTemplateId / description
      Previous value: -"Emergency template id (list_items kind emergency_templates). The template sets the screens; scope arguments are ignored."New value: +"Emergency template id."
    • changedInput schema / properties / expiresAt / description
      Previous value: -"ISO 8601 time the cast ends, e.g. \"2026-10-20T14:00:00-07:00\". Default: one hour from now."New value: +"End time."
    • changedInput schema / properties / headline / description
      Previous value: -"With contentId: the name the cast is listed under."New value: +"Listing name."
    • changedInput schema / properties / message / description
      Previous value: -"A new announcement to write and show."New value: +"New announcement."
    • changedInput schema / properties / scopeKind / description
      Previous value: -"Which screens: all (default, every screen this connection reaches), node (one location and below) or screens (a list)."New value: +"Which screens."
    • changedInput schema / properties / scopeNodeId / description
      Previous value: -"With scopeKind node: the location id."New value: +"Location id."
    • changedInput schema / properties / screenIds / description
      Previous value: -"With scopeKind screens: the screen ids, max 500."New value: +"Screen ids."
  4. Added

TDQS

A5/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that content self-expires, that an emergency persists above everything until end_takeover, that the call requires the screen.cast permission, and that it returns castId for the paired end_takeover tool. These are non-obvious operational traits (permission, lifecycle, follow-up call) that the destructive/openWorld hints alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded imperative sentence followed by tight labeled sections (when to use, when not to use, what to know, parameters). Every line carries decision-relevant information; no filler.

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 an 8-parameter mutation with an output schema, the description covers selection guidance, permission prerequisites, precedence rules, defaults, and the paired cleanup tool. With the output schema handling return shape, nothing material is missing.

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

Parameters5/5

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

Schema coverage is 100% so the baseline would be 3, but the description adds real meaning the schema lacks: the mutual-exclusion rule ('pass exactly one of contentId+contentKind or emergencyTemplateId'), the default for scopeKind and its per-value semantics, the emergency overriding scope, the one-hour default for expiresAt, and a worked example.

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?

States a concrete verb and resource ('show something on screens over their normal content, now') with an explicit temporary-behavior qualifier. The 'When NOT to use' line names set_screen_content, so an agent can separate it from the sibling without opening either schema.

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?

Gives explicit when-to-use cases (temporary override like a lunch menu, or a pre-armed emergency) and an explicit when-not-to-use case routed to set_screen_content. Emergency vs temporary content handling is also called out as a decision the agent must confirm with the person.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources