agentView

Send HTML

send_html

Destructive

Shows HTML content on a display: menus, dashboards, welcome pages, schedules or any custom design. slot 'live' (default) replaces the current content; slot 'idle' stores the default/fallback content shown when nothing live is active (idle requires admin scope). Always pass a short description so later content reads stay meaningful. Exactly one of html or base64_html. For external web pages use send_url; to edit current content call read_display_html first. For polished results load prompt render_premium_display_html or resource agentview://public/design-system. Requires content scope.

Input Schema

TableJSON Schema

Name	Required	Description
`html`	No	Complete HTML document to render. Mutually exclusive with base64_html.
`slot`	No	Target slot: 'live' (default) replaces current content; 'idle' sets the default shown when idle (admin scope).
`token`	No	Display-specific demo/preview token for unauthenticated access. NOT the OAuth token.
`duration`	No	Seconds the content stays; 0 = indefinite (default). Live slot only.
`display_id`	Yes	8-character display profile ID, e.g. 'ABCD1234'.
`base64_html`	No	Base64-encoded HTML (standard base64). Use only when raw HTML cannot survive JSON transport. Mutually exclusive with html.
`description`	Yes	Short human-readable summary of the content, e.g. 'Weekly KPI dashboard'.
`access_token`	No	Optional bearer token; prefer session_request_id. Distinct from the display-specific 'token'.
`session_request_id`	No	Session handle from create_auth_session; pass it on every authenticated call.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No
`name`	No
`idleFile`	No
`idleVersion`	No
`idleContentCleared`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 1, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "idleContentCleared": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "idleFile": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "idleVersion": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changed11 schema fields changedJul 6, 2026

changedInput schema / properties / access_token / description

Previous value: -"Optional bearer credential. Prefer passing session_request_id (from create_auth_session) instead; every tool accepts it and the server resolves it to your identity server-side. Use access_token only when you hold an OAuth bearer token and your MCP client cannot send it as an Authorization: Bearer HTTP header automatically. This is different from 'token' which is a display-specific preview token."New value: +"Optional bearer token; prefer session_request_id. Distinct from the display-specific 'token'."

changedInput schema / properties / base64_html / description

Previous value: -"Base64-encoded HTML string (standard base64, not base64url). Use this instead of html only when the HTML contains characters that cannot survive JSON string transport. Mutually exclusive with html."New value: +"Base64-encoded HTML (standard base64). Use only when raw HTML cannot survive JSON transport. Mutually exclusive with html."

removedInput schema / properties / content_description

Removed value: -{
-  "description": "Optional alias for description. If both are provided, description wins.",
-  "type": "string"
-}

changedInput schema / properties / description / description

Previous value: -"Mandatory short human-readable description of the HTML upload (1-1000 characters), e.g. 'Weekly KPI dashboard with revenue and uptime'."New value: +"Short human-readable summary of the content, e.g. 'Weekly KPI dashboard'."

changedInput schema / properties / display_id / description

Previous value: -"The 8-character alphanumeric display profile ID to send content to, e.g. 'ABCD1234'."New value: +"8-character display profile ID, e.g. 'ABCD1234'."

changedInput schema / properties / duration / description

Previous value: -"How long the content stays on the display in seconds. 0 means indefinite (content persists until replaced). Defaults to 0 when omitted."New value: +"Seconds the content stays; 0 = indefinite (default). Live slot only."

changedInput schema / properties / html / description

Previous value: -"Complete HTML document or fragment to render on the display. Mutually exclusive with base64_html — provide exactly one."New value: +"Complete HTML document to render. Mutually exclusive with base64_html."

addedInput schema / properties / session_request_id

Added value: +{
+  "description": "Session handle from create_auth_session; pass it on every authenticated call.",
+  "type": "string"
+}

addedInput schema / properties / slot

Added value: +{
+  "description": "Target slot: 'live' (default) replaces current content; 'idle' sets the default shown when idle (admin scope).",
+  "enum": [
+    "live",
+    "idle"
+  ],
+  "type": "string"
+}

changedInput schema / properties / token / description

Previous value: -"Display-specific preview token for unauthenticated demo-sign access. This is NOT the auth/JWT token. Omit this for normal authenticated usage."New value: +"Display-specific demo/preview token for unauthenticated access. NOT the OAuth token."

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "currentContentDescription": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "duration": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "file": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "id": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "name": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "version": {
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null

Changed6 schema fields changedJun 2, 2026

changedOutput schema / properties / currentContentDescription / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / duration / type

Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]

changedOutput schema / properties / file / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / id / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / name / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / properties / version / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

Changed1 schema field changedMay 30, 2026

changedInput schema / properties / access_token / description

Previous value: -"Optional JWT access token for authentication. Pass the token returned by get_auth_session when your MCP client does not send it as an Authorization: Bearer HTTP header automatically. This is different from 'token' which is a display-specific preview token."New value: +"Optional bearer credential. Prefer passing session_request_id (from create_auth_session) instead; every tool accepts it and the server resolves it to your identity server-side. Use access_token only when you hold an OAuth bearer token and your MCP client cannot send it as an Authorization: Bearer HTTP header automatically. This is different from 'token' which is a display-specific preview token."

Changed20 schema fields changedMay 23, 2026

removedInput schema / properties / access_token / default
```
Removed value: -null
```

changedInput schema / properties / access_token / description

Previous value: -"Optional JWT access token for authentication. Pass the token returned by get_auth_session when your MCP client does not send it as an Authorization: Bearer HTTP header automatically. This is different from the 'token' parameter which is a display-specific preview token."New value: +"Optional JWT access token for authentication. Pass the token returned by get_auth_session when your MCP client does not send it as an Authorization: Bearer HTTP header automatically. This is different from 'token' which is a display-specific preview token."

changedInput schema / properties / access_token / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

removedInput schema / properties / base64_html / default
```
Removed value: -null
```

changedInput schema / properties / base64_html / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

removedInput schema / properties / content_description / default
```
Removed value: -null
```

changedInput schema / properties / content_description / description

Previous value: -"Optional human-readable summary of what this content is. Priority: explicit content_description > stored description > technical fallback."New value: +"Optional alias for description. If both are provided, description wins."

changedInput schema / properties / content_description / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

addedInput schema / properties / description / maxLength
```
Added value: +1000
```
addedInput schema / properties / description / minLength
```
Added value: +1
```
removedInput schema / properties / duration / default
```
Removed value: -null
```
addedInput schema / properties / duration / minimum
```
Added value: +0
```

changedInput schema / properties / duration / type

Previous value: -[
-  "integer",
-  "null"
-]New value: +"integer"

removedInput schema / properties / html / default
```
Removed value: -null
```

changedInput schema / properties / html / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

removedInput schema / properties / session_request_id

Removed value: -{
-  "default": null,
-  "description": "Optional session request ID returned by create_auth_session. Pass this instead of access_token for simpler, more reliable authentication — the server resolves the identity server-side.",
-  "type": [
-    "string",
-    "null"
-  ]
-}

removedInput schema / properties / token / default
```
Removed value: -null
```

changedInput schema / properties / token / description

Previous value: -"Display-specific preview token for unauthenticated demo-sign access. This is NOT the auth/JWT token — it is a short-lived token obtained from the display's preview flow. Omit this for normal authenticated usage."New value: +"Display-specific preview token for unauthenticated demo-sign access. This is NOT the auth/JWT token. Omit this for normal authenticated usage."

changedInput schema / properties / token / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "currentContentDescription": {
+      "type": "string"
+    },
+    "duration": {
+      "type": "integer"
+    },
+    "file": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "version": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedMay 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses exactly what gets affected: the 'live' slot replaces current content, while 'idle' stores fallback content. It also reveals authentication requirements ('idle requires admin scope', 'Requires content scope') and explains why a description parameter matters ('so later content reads stay meaningful'). This adds meaningful behavioral context beyond the structured 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 dense but front-loaded with the core purpose. Every sentence contributes something important—slot semantics, mutual exclusivity, alternatives, scope, and design resources. It is slightly longer than strictly necessary, but the information is well-ordered and free of 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 a tool with 9 parameters and an output schema, the description covers the critical operational context: slot behavior, encoding constraint, required description, scope requirements, and alternatives. It doesn't need to explain return values because the output schema exists, and it doesn't omit any information an agent needs to call the tool correctly.

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 parameters are already well-documented. The description still adds value by emphasizing the mutual exclusivity between html and base64_html, and by instructing the agent to always provide a short description. It does not repeat every schema detail, but the added cross-parameter guidance lifts it above the baseline.

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 names a specific action ('Shows HTML content on a display') and identifies the resource (a display) with concrete use cases (menus, dashboards, schedules). It further distinguishes itself by naming alternatives: 'For external web pages use send_url; to edit current content call read_display_html first.' This makes the tool's purpose unmistakable and separates it from related siblings.

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?

The description gives explicit when-to-use guidance: it tells the agent to use send_url for external pages and read_display_html before editing current content. It also states hard usage rules like 'Exactly one of html or base64_html', 'Always pass a short description', and the admin-scope requirement for the idle slot. This is clearly actionable guidance for selecting and invoking the tool.

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

All agentView tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools map cleanly to distinct resource-action pairs (displays, organizations, assets, data slots, store templates, auth). A few clusters like the get_store_template_* family and the auth/session tools could still confuse an agent, but their descriptions are explicit enough to separate them.

Naming Consistency4/5

The dominant pattern is consistent verb_noun snake_case (list_*, get_*, create_*, delete_*, send_*, set_*, manage_*). Deviations like fetch, search, authenticate, logout, and pair_by_code are understandable but break the otherwise uniform naming scheme.

Tool Count1/5

With 57 tools this server far exceeds the 50+ threshold, creating an extreme tool-set size for an MCP server. Even though the underlying platform is feature-rich, the sheer number of tools heavily taxes context and selection.

Completeness4/5

The surface covers display, organization, asset, data slot, store template, auth, API key, and licensing lifecycles in impressive depth. Minor gaps exist, such as no delete operation for display categories and no reboot/power control for displays.

Resources

Need Help?