agentView

Read Display HTML

read_display_html

Read-onlyIdempotent

Reads the raw HTML source currently shown on a display so you can inspect or edit it and push it back with send_html. content_type 'idle' reads the default/fallback content instead. Responses are windowed for large documents: max_bytes (default 51200) and offset page through the source; the result reports totalBytes and truncated. Not for visual previews (use get_display_preview_url). Requires content scope.

Input Schema

TableJSON Schema

Name	Required	Description
`offset`	No	Byte offset to start reading from. Default 0.
`max_bytes`	No	Maximum bytes of HTML to return. Default 51200.
`display_id`	Yes	8-character display profile ID, e.g. 'ABCD1234'.
`access_token`	No	Optional bearer token; prefer session_request_id.
`content_type`	No	'live' (default) reads active content; 'idle' reads default content.
`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
`html`	No
`name`	No
`offset`	No
`source`	No
`truncated`	No
`hasContent`	No
`htmlLength`	No
`totalBytes`	No
`contentType`	No

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations (readOnly, idempotent, not destructive), the description adds key behaviors: windowed reading with max_bytes and offset, reporting totalBytes and truncated. No contradiction.

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?

Four sentences front-load purpose, then add paging details, then exclusion. No wasted words; every sentence adds value.

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?

Given 6 parameters, 1 required, and an output schema (not shown but acknowledged), the description covers purpose, windowing, alternatives, and prerequisite (content scope). Complete for agent invocation.

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%, baseline 3. Description adds context on paging behavior (max_bytes default, offset) and content_type explanation beyond enum values, but mostly reinforces schema.

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 it reads raw HTML source shown on a display, distinguishes from get_display_preview_url for visual previews, and explains the content_type parameter for idle vs live content. The verb 'reads' and resource 'HTML source' are specific.

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?

Explicitly says not for visual previews and directs to get_display_preview_url. Mentions pushing back with send_html. But does not provide guidance on when to use access_token vs session_request_id or prerequisites like content scope.

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?