Skip to main content
Glama
Sign In

Brix Digital Signage

by com.brixsignage
OverviewDiscussionsAdmin

Read items in full

get_items
Read-onlyIdempotent

Read items of one kind in full.

When to use:

  • Before update_items, to see current values and part ids (playlist items pli_…, schedule blocks sb_…).

  • Checking how many rows of a sheet a repeating creative plays, and how many fit.

  • Checking an approval request, a fired emergency, a device test run, a person's locations and roles, a role's permissions, or who this connection is (kind account).

When NOT to use:

  • Searching by name: use list_items first.

  • Why a screen is blank, its outages or its TV state: use get_screen_status (get_items returns a screen's settings and assigned content).

What to know:

  • Returns a playlist's items in order, a schedule's blocks, a layout's zones, an app's config, a screen's status and content.

  • A creative that repeats for each row also returns repeatStatus: rowCount and rowsThatFit (what the last sync holds and how many play), limitedBy (rows, bytes or null), loopSeconds, columns (each header and its row tag), missingColumns, firstRowBindings, lastSyncedAt and warnings to pass on. rowCount is null when this connection cannot read that data source.

  • Sign-in details of feeds and web links stay in the Brix console: a stored one reads as ••••••••, never as its value. Items outside this connection's locations read as not found.

Parameters:

  • kind: the kind of every id. account takes no ids and returns this connection's actor, workspace and permissions.

  • ids: prefix-typed ids from list_items (pl_… playlist, scr_… screen, sch_… schedule); required for every kind but account. Each id returns its item or not found; the rest still return.

  • device_test_runs: call again until status is finished.

  • Example: {kind:"playlists", ids:["pl_8f2c"]}.

Input Schema

NameRequiredDescriptionDefault
idsNoItem ids.
kindYesKind of the ids.

Output Schema

NameRequiredDescriptionDefault
kindNoThe kind that was acted on.
failedNoHow many failed; the rest still ran.
resultsNoOne row per id or item, in the order given.
succeededNoHow many ids or items succeeded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "screens",
-  "media",
-  "playlists",
-  "schedules",
-  "layouts",
-  "creatives",
-  "apps",
-  "data_sources",
-  "screen_groups",
-  "locations",
-  "media_folders",
-  "emergency_templates",
-  "approvals",
-  "emergencies",
-  "device_test_runs",
-  "account"
-]New value: +[
+  "screens",
+  "media",
+  "playlists",
+  "schedules",
+  "layouts",
+  "creatives",
+  "apps",
+  "data_sources",
+  "screen_groups",
+  "locations",
+  "media_folders",
+  "emergency_templates",
+  "approvals",
+  "emergencies",
+  "device_test_runs",
+  "people",
+  "roles",
+  "account"
+]
  2. Changed2 schema fields changed
    • changedInput schema / properties / ids / description
      Previous value: -"Item ids, 1 to 50, from list_items (e.g. pl_… for a playlist, scr_… for a screen)."New value: +"Item ids."
    • changedInput schema / properties / kind / description
      Previous value: -"The kind of every id. account takes no ids."New value: +"Kind of the ids."
  3. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, yet the description still adds real operational context: per-id partial failure ('Each id returns its item or not found; the rest still return'), redaction of stored feed/link credentials, out-of-scope items surfacing as not found, rowCount being null when the data source is unreadable, and the polling instruction for device_test_runs. The only shortfall is that it does not mention the 50-id cap enforced by the schema or response size/pagination characteristics.

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?

Front-loaded with the core statement, then cleanly sectioned into when/when-not/what-to-know/parameters, so an agent can skim to what it needs. It runs long and some of the repeatStatus field inventory (loopSeconds, columns, missingColumns, firstRowBindings) is arguably return-value detail that the output schema already carries.

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 2-parameter tool spanning 18 kind values with heterogeneous return shapes, the description covers the selection decision, id construction, partial failure semantics, credential redaction and the one special kind. With an output schema present it need not enumerate return fields, and the extra detail on repeating creatives is helpful rather than redundant.

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 already 100%, so this had a low bar, but the description still adds genuine meaning: ids are prefix-typed (pl_, scr_, sch_) and sourced from list_items, they are required for every kind except account, and each id independently succeeds or fails. The worked example plus the account special case ('takes no ids and returns this connection's actor, workspace and permissions') tells an agent how to construct calls for an enum value the schema cannot explain.

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 a specific verb and resource ('Read items of one kind in full') and immediately separates itself from the two siblings an agent would most plausibly confuse it with — list_items for name search and get_screen_status for screen health. The reader knows it is a full-detail fetch keyed by kind and ids.

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?

Explicit 'When to use' / 'When NOT to use' sections name concrete preconditions (before update_items to capture part ids) and redirect to the correct alternatives (list_items, get_screen_status) with the reason for each. Nothing about tool selection is left to inference.

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

All Brix Digital Signage 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