Skip to main content
Glama
Sign In
MCP Server Tauri

MCP Server Tauri

by hypothesi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

webview_screenshot

Read-only

[Tauri Apps Only] Screenshot a running Tauri app's webview. Requires active driver_session. Captures only visible viewport. Targets the only connected app, or the default app if multiple are connected.

Instructions

[Tauri Apps Only] Screenshot a running Tauri app's webview. Requires active driver_session. Captures only visible viewport. Targets the only connected app, or the default app if multiple are connected. Specify appIdentifier (port or bundle ID) to target a specific app. For browser screenshots, use Chrome DevTools MCP instead. For Electron apps, this will NOT work.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "webview_screenshot"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatNoImage formatjpeg
qualityNoJPEG quality (0-100, only for jpeg format)
filePathNoFile path to save the screenshot to instead of returning as base64
maxWidthNoMaximum width in pixels. Images wider than this will be scaled down proportionally. Can also be set via TAURI_MCP_SCREENSHOT_MAX_WIDTH environment variable.
windowIdNoWindow label to target (defaults to "main")
appIdentifierNoApp port or bundle ID to target. Defaults to the only connected app or the default app if multiple are connected.
allowScreenCaptureNoAllow an interactive OS screen-sharing permission prompt if native and html2canvas capture fail

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.1
    • addedInput schema / properties / allowScreenCapture
      Added value: +{
+  "default": false,
+  "description": "Allow an interactive OS screen-sharing permission prompt if native and html2canvas capture fail",
+  "type": "boolean"
+}
  2. Addedv0.11.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the bar is lower, yet the description still adds real behavior: the driver_session prerequisite and the fact that only the visible viewport is captured. It also explains the app-targeting resolution rule (only connected app, or default app if multiple). It does not surface the interactive OS screen-sharing permission prompt path, leaving that to the schema.

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 with the scope constraint and precondition, then the exclusions. Every sentence carries routing or behavioral information; nothing is padded.

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?

For a zero-required-parameter, no-output-schema capture tool, the description covers scope, prerequisite, targeting resolution, and exclusions. The only omission is what the call returns, but the schema's filePath description ('instead of returning as base64') already covers output form.

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 description coverage is 100%, and every parameter (format, quality, filePath, maxWidth, windowId, allowScreenCapture) is documented in the schema itself. The description's appIdentifier note ('port or bundle ID') largely restates the schema's own text, so it adds little beyond 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?

States a specific verb ('Screenshot') and resource ('a running Tauri app's webview'), immediately scoped by '[Tauri Apps Only]'. It also explicitly rules out the two nearest alternatives (Chrome DevTools MCP for browsers, Electron apps), so the agent can distinguish it from everything in the sibling list.

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 an explicit precondition ('Requires active driver_session') and names when NOT to use it ('For browser screenshots, use Chrome DevTools MCP instead. For Electron apps, this will NOT work'). This is textbook when/when-not/alternative routing.

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

Deploy Server

Other Tools