whodb-cli

Official

Overview Schema Source Related Servers Discussions Admin

whodb_platform_app_screenshot

Read-onlyIdempotent

Capture a rendered app page at desktop, mobile, or tablet sizes after clicks, fills, or JavaScript, returning a WebP image, visible text, and diagnostics for visual verification.

Instructions

Capture a rendered app page at desktop, mobile, or tablet size after optional actions or JavaScript. Returns a WebP image, visible text, diagnostics, and an optional interaction trace on compatible runtimes. Hosted writes are blocked. Accepts workspace {host, org, project} for per-call targeting without changing defaults.

Input Schema

Name	Required	Description
`app`	Yes	App ID or exact name in the selected project
`env`	No	published (default) or dev
`tab`	No	Optional visible tab or button label to open before capture
`page`	No	Optional page returned by whodb_platform_app_views
`trace`	No	Request an interaction trace from a compatible hosted app runtime
`width`	No	Viewport width, default 1440
`height`	No	Viewport height, default 900
`mobile`	No	Emulate a touch-enabled mobile browser; default viewport 390x844 unless width or height is set
`script`	No	Optional JavaScript expression or IIFE evaluated inside the app frame after actions
`tablet`	No	Emulate a touch-enabled tablet browser; default viewport 820x1180 unless width or height is set
`actions`	No	Ordered actions inside the app frame: click, fill, press, wait_for, or wait
`workspace`	No	Optional target for this call only. Omit to use the session default set by whodb_platform_session_use, then process/saved defaults. Discover targets with whodb_platform_hosts, whodb_platform_orgs and whodb_platform_projects.
`orientation`	No	Optional viewport orientation: portrait or landscape; rotates the device preset

Output Schema

Name	Required	Description
`app`	No
`env`	No
`tab`	No
`page`	No
`error`	No
`scope`	No
`trace`	No
`width`	No
`app_id`	No
`height`	No
`mobile`	No
`tablet`	No
`recovery`	No
`mime_type`	No
`retryable`	No
`workspace`	No	Optional target for this call only. Omit to use the session default set by whodb_platform_session_use, then process/saved defaults. Discover targets with whodb_platform_hosts, whodb_platform_orgs and whodb_platform_projects.
`error_code`	No
`request_id`	No
`diagnostics`	Yes
`orientation`	No
`visible_text`	No
`checks_passed`	Yes
`suggested_tools`	No
`script_result_json`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.136.0Oct 23, 2026

addedOutput schema / properties / error_code
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / recovery

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "LikelyCause": {
+      "type": "string"
+    },
+    "NextSteps": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "null",
+        "array"
+      ]
+    }
+  },
+  "required": [
+    "LikelyCause",
+    "NextSteps"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / retryable
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / suggested_tools

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Addedv0.135.0Oct 15, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds real behavioral context: it discloses the returned artifacts (WebP, text, diagnostics, optional trace), the runtime compatibility caveat for traces, and that hosted writes are blocked. It stops short of explaining failure modes or pagination/diagnostics semantics, so not a full 5.

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 purpose, then returns and targeting constraints in compact sentences. Dense but each clause carries information; only slight redundancy with the annotation title text.

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

Completeness4/5

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

With 13 params, nested workspace, an output schema, and full annotations, the description covers the essentials an agent needs (device presets, actions/script, targeting, blocked writes). Missing only explicit guidance on when a trace is available or how diagnostics should be interpreted.

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

Parameters3/5

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

Schema coverage is 100%, so both the flat fields and the nested workspace object are already documented. The description reiterates workspace targeting and defaults but adds little syntactic detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 specific verb (capture) plus resource (rendered app page) and the distinguishing capabilities (device sizes, post-actions/JS, returned artifacts). An agent can tell this apart from read-only siblings like whodb_platform_app_views or whodb_platform_app_view, which merely list or fetch views.

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

Usage Guidelines3/5

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

The description implies context (rendering a page with optional actions before capture) and the workspace field points to discovery tools, but it never explicitly says when to use this versus app_view/app_views, nor any prerequisite or exclusion conditions. Usage is inferable rather than stated.

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

Deploy Server