Skip to main content
Glama

screenstudio_find_sensitive

Detect private text like emails, API keys, and card numbers in screen recordings, then propose blur masks to hide them before publishing.

Instructions

Find private text in the footage before publishing and propose blur masks for it. Reads frames (every everyMs plus just before and after each screen change) with macOS text recognition and looks for emails, phone numbers (including +E.164 and labelled digits), API keys and tokens (sk-, ghp_, xox, AKIA, AWS secret keys, Stripe, Google, private key headers), JSON web tokens, hex keys and hashes (32+ hex digits with letters; digit-only IDs such as post IDs in links, and IDs run into hex at either end, are not flagged), long random strings, card numbers (Luhn checked), IP addresses, links carrying tokens (with or without https://), passwords and secrets in settings, .env lines and connection strings, and any extraTerms (plain words, or /regex/flags; a term inside a longer secret widens the blur to the whole secret). Long recordings are read end to end: the frame grid widens to fit maxFrames. Each finding is followed across frames into one span with a padded box (0-1 of the capture). Returns detections with a masked preview (never the full value), a preview sheet of up to six frames that show the findings (each at least 960px wide, every blur filled red, existing blur masks included, every finding seen there ringed in yellow and numbered, with its kind and masked value listed under the frame), notes explaining the choices, and addMask sensitive-data ops for screenstudio_editor_apply. With apply: true the masks are added live in the open editor (undoable, then saved). An existing blur mask grows to cover new findings; a highlight or disabled mask blocks a blur, and the notes say where. ignore drops kinds that are expected on screen (custom, api-key, jwt, url-token, credential, email, card, phone, ipv4, hex-secret, base64-secret).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
applyNo
ignoreNo
everyMsNo
maxFramesNo
extraTermsNo
projectPathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnly=false/destructive=false; the description goes far beyond by disclosing that apply:true mutates live and is undoable-then-saved, that an existing blur mask grows to cover new findings, and that a highlight or disabled mask blocks a blur. It also details the return payload and the detection pipeline, none of which structured fields provide.

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?

Purpose is front-loaded and almost every clause is functional, but the single dense paragraph and the rendering minutiae of the preview sheet (960px, red fills, yellow rings) push past what an agent needs to invoke the tool. Efficient overall, mildly bloated in places.

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?

There is no output schema, so the description carries the full burden and does: it enumerates the returned detections, masked preview, preview sheet, notes, and addMask ops, plus mutation side effects. Nothing needed to call or interpret the tool correctly is missing.

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?

With 0% schema description coverage the description must carry the params, and it does: apply (live vs preview), ignore (drops expected kinds, enum explained semantically), everyMs/maxFrames (frame-grid behavior), extraTerms (plain words or /regex/flags, and that a term inside a longer secret widens the blur), and projectPath implicitly. It adds real meaning beyond the bare schema types.

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+resource ('Find private text in the footage... propose blur masks') and the scope is unmistakable. No sibling tool does sensitive-data detection, so the agent can route to it on name/description alone.

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?

Frames the use case ('before publishing') and distinguishes the preview mode from 'apply: true' (masks added live in the open editor), and names screenstudio_editor_apply as the consumer of its ops. It stops short of explicit when-not-to-use guidance, but the default-off vs apply-on split is a clear contextual cue.

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