PeepIt MCP
Enables AI agents to capture screenshots of macOS screens, applications, and windows using Apple's ScreenCaptureKit, with support for listing running apps and windows for targeted captures.
Enables local AI-powered visual analysis of screenshots using Ollama vision models (llava, qwen2-vl) without sending data to cloud services.
Provides AI-powered visual analysis of screenshots using OpenAI's GPT-4o vision model to answer questions about captured screen content.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@PeepIt MCPtake a screenshot of Safari and tell me what's on the page"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
PeepIt MCP: Lightning-fast macOS Screenshots for AI Agents

PeepIt: Because Your AI Deserves to See What You See
Ever wish your AI assistant could just look at your screen and get it? PeepIt is here to grant your digital sidekick the gift of sight—no magic wands required. Whether you're debugging a UI, capturing a bug in the wild, or just want to know what's lurking behind that mysterious window, PeepIt's got your back (and your screen).
What is PeepIt?
PeepIt is a macOS-only MCP server that lets AI agents capture screenshots of your apps, windows, or the whole system—then analyze them with local or cloud-based AI models. It's like giving your AI a pair of glasses and a magnifying glass, all in one.
Capture screenshots of anything: the whole screen, a single app, or that one window you can never find
Analyze visual content with AI vision models (local or cloud—your call)
List running apps and windows for laser-targeted captures
Work non-intrusively—no window focus stealing, no workflow interruptions, no drama
Related MCP server: MCP Screenshot Server
Key Features
🚀 Fast & Non-intrusive: Blink and you'll miss it—PeepIt uses Apple's ScreenCaptureKit for lightning-fast screenshots, all without hijacking your window focus or interrupting your groove.
🎯 Smart Window Targeting: Fuzzy matching so sharp, it'll find the right window even if you only remember half its name (we've all been there).
🤖 AI-Powered Analysis: Ask questions about your screenshots and get answers from GPT-4o, Claude, or local models—because sometimes you need a second set of (robotic) eyes.
🔒 Privacy-First: Prefer to keep things on the down-low? Run everything locally with Ollama, or call in the cloud cavalry only when you really need it.
📦 Easy Installation: One-click install via Cursor, or just a quick npm/npx incantation—no arcane rituals required.
🛠️ Developer-Friendly: Clean JSON API, TypeScript support, and logs so comprehensive you'll wonder if PeepIt is secretly writing your memoirs.
Installation
Requirements
macOS 14.0+ (Sonoma or later)
Node.js 20.0+
Screen Recording Permission (don't worry, you'll be prompted—no need to go spelunking in System Settings)
Quick Start
For Cursor IDE
Or manually add to your Cursor settings:
{
"mcpServers": {
"peepit": {
"command": "npx",
"args": [
"-y",
"@mantisware/peepit-mcp"
],
"env": {
"PEEPIT_AI_PROVIDERS": "openai/gpt-4o,ollama/llava:latest",
"OPENAI_API_KEY": "your-openai-api-key-here"
},
"toolCallTimeoutMillis": 120000
}
}
}For Claude Desktop
Edit your Claude Desktop configuration file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Add the PeepIt configuration (copy, paste, and you're halfway to AI vision):
{
"mcpServers": {
"peepit": {
"command": "npx",
"args": [
"-y",
"@mantisware/peepit-mcp"
],
"env": {
"PEEPIT_AI_PROVIDERS": "openai/gpt-4o,ollama/llava:latest",
"OPENAI_API_KEY": "your-openai-api-key-here"
}
}
}
}Then restart Claude Desktop. (Yes, you really do have to restart it. We checked.)
Configuration
PeepIt is as configurable as your favorite text editor. Use environment variables to tune it to your workflow:
{
"PEEPIT_AI_PROVIDERS": "openai/gpt-4o,ollama/llava:latest",
"OPENAI_API_KEY": "your-openai-api-key-here",
"PEEPIT_LOG_LEVEL": "debug",
"PEEPIT_LOG_FILE": "~/Library/Logs/peepit-mcp-debug.log",
"PEEPIT_DEFAULT_SAVE_PATH": "~/Pictures/PeepItCaptures",
"PEEPIT_CONSOLE_LOGGING": "true",
"PEEPIT_CLI_TIMEOUT": "30000",
"PEEPIT_CLI_PATH": "/opt/custom/peepit"
}Available Environment Variables
Variable | Description | Default |
| Who's your AI? List providers for image analysis (see AI Analysis). |
|
| How chatty should PeepIt be? (trace, debug, info, warn, error, fatal) |
|
| Where to stash the logs. If the directory isn't writable, PeepIt finds a cozy temp folder. |
|
| Default directory for screenshots when you don't specify a path. | System temp directory |
| Where's your Ollama API? Only needed if it's not at the usual spot. |
|
| Want logs in your console? Set to |
|
| How long to wait for Swift CLI magic (ms). |
|
| Custom path to the Swift | (uses bundled CLI) |
AI Provider Configuration
The PEEPIT_AI_PROVIDERS variable is your golden ticket to AI-powered screenshot analysis. Want PeepIt to answer questions about your screen? Just list your favorite models:
PEEPIT_AI_PROVIDERS="openai/gpt-4o,ollama/llava:latest,anthropic/claude-3-haiku-20240307"
Or, if you're a semicolon connoisseur:
PEEPIT_AI_PROVIDERS="openai/gpt-4o;ollama/llava:latest;anthropic/claude-3-haiku-20240307"
Each entry is provider_name/model_identifier. Supported providers: ollama (for local), openai (for the cloud), and soon, anthropic (for the truly adventurous).
PeepIt will try providers in order, checking for API keys or local services as needed. You can override the model per request if you're feeling particular.
Setting Up Local AI with Ollama
Ollama brings AI vision to your desktop—no cloud required, no data leaving your Mac. (Your secrets are safe. Probably.)
Installing Ollama
brew install ollama
# Or download from https://ollama.ai
ollama serveDownloading Vision Models
For beefy machines:
ollama pull llava:latest
ollama pull llava:7b-v1.6
ollama pull llava:13b-v1.6 # For the RAM-rich
ollama pull llava:34b-v1.6 # For the RAM-obsessedFor lighter laptops:
ollama pull qwen2-vl:7bModel Size Guide:
qwen2-vl:7b- ~4GB download, ~6GB RAM (great for mortals)llava:7b- ~4.5GB download, ~8GB RAMllava:13b- ~8GB download, ~16GB RAMllava:34b- ~20GB download, ~40GB RAM (bring snacks)
Configuring PeepIt with Ollama
Add Ollama to your Claude Desktop config:
{
"mcpServers": {
"peepit": {
"command": "npx",
"args": [
"-y",
"@mantisware/peepit-mcp@beta"
],
"env": {
"PEEPIT_AI_PROVIDERS": "ollama/llava:latest"
}
}
}
}For lighter machines:
{
"mcpServers": {
"peepit": {
"command": "npx",
"args": [
"-y",
"@mantisware/peepit-mcp@beta"
],
"env": {
"PEEPIT_AI_PROVIDERS": "ollama/qwen2-vl:7b"
}
}
}
}Mix and match AI providers:
{
"env": {
"PEEPIT_AI_PROVIDERS": "ollama/llava:latest,openai/gpt-4o",
"OPENAI_API_KEY": "your-api-key-here"
}
}macOS Permissions
PeepIt needs a few macOS permissions to work its magic. Don't worry, it's not asking for your Netflix password.
1. Screen Recording Permission (Required)
macOS Sequoia (15.0+):
System Settings → Privacy & Security
Scroll to Screen & System Audio Recording
Toggle on your terminal or MCP client
Restart the app (yes, again)
macOS Sonoma (14.0) and earlier:
System Preferences → Security & Privacy → Privacy
Select Screen Recording
Click the lock, enter your password
Add your terminal or MCP client
Restart the app
Apps that need permission:
Terminal.app
Claude Desktop
VS Code
Cursor
2. Accessibility Permission (Optional, but nice)
macOS Sequoia (15.0+):
System Settings → Privacy & Security → Accessibility
Toggle on your terminal/MCP client
macOS Sonoma (14.0) and earlier:
System Preferences → Security & Privacy → Privacy
Select Accessibility
Add your terminal/MCP client
Testing & Debugging
Using MCP Inspector
Want to see PeepIt in action? Fire up the MCP Inspector:
# Test with OpenAI
OPENAI_API_KEY="your-key" PEEPIT_AI_PROVIDERS="openai/gpt-4o" npx @modelcontextprotocol/inspector npx -y @mantisware/peepit-mcp
# Test with local Ollama
PEEPIT_AI_PROVIDERS="ollama/llava:latest" npx @modelcontextprotocol/inspector npx -y @mantisware/peepit-mcpDirect CLI Testing
./peepit --help
./peepit list server_status --json-output
./peepit image --mode screen --format png
peepit-mcpExpected output:
{
"success": true,
"data": {
"swift_cli_available": true,
"permissions": {
"screen_recording": true
},
"system_info": {
"macos_version": "14.0"
}
}
}Available Tools
PeepIt gives you three main tools—think of them as your AI's Swiss Army knife:
1. image - Capture Screenshots
Snap a screenshot of your Mac—screen, app, or window. Shadows and frames? Gone. (You're welcome.)
Note: Screen captures are always saved to files (no Base64 for giant images—your stack won't like it). If you ask for format: "data", PeepIt will politely ignore you and save a PNG instead, with a gentle warning.
Examples:
// Capture entire screen
await use_mcp_tool("peepit", "image", {
app_target: "screen:0",
path: "~/Desktop/screenshot.png"
});
// Capture a specific app window and analyze it
await use_mcp_tool("peepit", "image", {
app_target: "Safari",
question: "What website is currently open?",
format: "data"
});
// Capture window by title
await use_mcp_tool("peepit", "image", {
app_target: "Notes:WINDOW_TITLE:Meeting Notes",
path: "~/Desktop/notes.png"
});
// Capture the frontmost window
await use_mcp_tool("peepit", "image", {
app_target: "frontmost",
format: "png"
});
// Capture by Process ID
await use_mcp_tool("peepit", "image", {
app_target: "PID:663",
path: "~/Desktop/process.png"
});Browser Helper Filtering: PeepIt is smart enough to avoid browser helper processes (no more "Google Chrome Helper (Renderer)" shenanigans). You'll get the real browser window, or a clear message if it's not running.
File Naming and Path Behavior:
Single capture? Your path is used as-is.
Multiple captures? PeepIt adds metadata to filenames so nothing gets overwritten.
Directory path? PeepIt generates unique names for you.
Long filenames? PeepIt trims them to fit macOS's 255-byte limit, keeping your emoji and non-Latin scripts intact.
Invalid formats? Only PNG and JPEG are allowed. Anything else gets converted, with a friendly warning.
2. list - System Information
List running apps, windows, or check server status. Because sometimes you just need to know what's out there.
Examples:
// List all running apps
await use_mcp_tool("peepit", "list", {
item_type: "running_applications"
});
// List windows of a specific app
await use_mcp_tool("peepit", "list", {
item_type: "application_windows",
app: "Preview"
});
// List windows by PID
await use_mcp_tool("peepit", "list", {
item_type: "application_windows",
app: "PID:663"
});
// Check server status
await use_mcp_tool("peepit", "list", {
item_type: "server_status"
});3. analyze - AI Vision Analysis
Feed an image to your AI and ask it anything. (Well, almost anything.)
Examples:
// Analyze with auto-selected provider
await use_mcp_tool("peepit", "analyze", {
image_path: "~/Desktop/screenshot.png",
question: "What applications are visible?"
});
// Force a specific provider
await use_mcp_tool("peepit", "analyze", {
image_path: "~/Desktop/diagram.jpg",
question: "Explain this diagram",
provider_config: {
type: "ollama",
model: "llava:13b"
}
});Testing
PeepIt comes with tests galore:
TypeScript Tests
Unit Tests: For the code that likes to be alone
Integration Tests: For the code that plays well with others
Platform-Specific Tests: Some tests need macOS and the Swift binary
npm test # Run all tests (macOS required for full suite)
npm run test:unit # Unit tests only (any platform)
npm run test:typescript # TypeScript-only tests (Linux-friendly)
npm run test:typescript:watch # Watch mode
npm run test:coverage # With coverageSwift Tests
npm run test:swift # Swift CLI tests (macOS only)
npm run test:integration # Full integration (TypeScript + Swift)Platform Support
macOS: All tests
Linux/CI: TypeScript-only (Swift tests are skipped)
Env Vars:
SKIP_SWIFT_TESTS=true: Skip Swift testsCI=true: Skip Swift tests automatically
Troubleshooting
Haunting | Exorcism |
| Grant Screen Recording permission. Restart the app. |
Window capture issues | Grant Accessibility permission for more reliable targeting. |
| Make sure the |
| Check your AI provider config and API keys. Make sure local services are running. Check logs for details. |
| Ensure your PATH includes npm binaries, or use the right command. |
General weirdness | Check the logs! Set |
Debug Mode
OPENAI_API_KEY="your-key" PEEPIT_AI_PROVIDERS="openai/gpt-4o" PEEPIT_LOG_LEVEL=debug PEEPIT_CONSOLE_LOGGING=true npx @mantisware/peepit-mcp
./peepit list server_status --json-outputGetting Help
Building from Source
Development Setup
git clone https://github.com/mantisware/peepit.git
cd peepit
npm install
npm run build
cd peepit-cli
swift build -c release
cp .build/release/peepit ../peepit
cd ..
npm link # Optional: install globallyLocal Development Configuration
For local dev:
{
"mcpServers": {
"peepit_local": {
"command": "peepit-mcp",
"args": [],
"env": {
"PEEPIT_LOG_LEVEL": "debug",
"PEEPIT_CONSOLE_LOGGING": "true"
}
}
}
}Or, running directly with node:
{
"mcpServers": {
"peepit_local_node": {
"command": "node",
"args": [
"/Users/mantisware/Projects/PeepIt/dist/index.js"
],
"env": {
"PEEPIT_LOG_LEVEL": "debug",
"PEEPIT_CONSOLE_LOGGING": "true"
}
}
}
}Use absolute paths and unique server names to avoid confusion.
AppleScript Version (Legacy)
For the old-school crowd:
osascript peepit.scptNote: No AI analysis or MCP features in this version.
Manual Configuration for Other MCP Clients
{
"server": {
"command": "node",
"args": ["/path/to/peepit/dist/index.js"],
"env": {
"PEEPIT_AI_PROVIDERS": "openai/gpt-4o,ollama/llava",
"OPENAI_API_KEY": "your-openai-api-key-here"
}
}
}Tool Documentation
image - Screenshot Capture
Capture your Mac's screen and optionally analyze it. Shadows and frames are automatically banished.
Parameters:
app_target(string, optional): Specifies the capture target. If omitted or empty, captures all screens.Examples:
"screen:INDEX": Captures the screen at the specified zero-based index (e.g.,"screen:0"). (Note: Index selection from multiple screens is planned for full support in the Swift CLI)."frontmost": Captures the frontmost window of the currently active application."AppName": Captures all windows of the application namedAppName(e.g.,"Safari","com.apple.Safari"). Fuzzy matching is used."PID:ProcessID": Captures all windows of the application with the specified process ID (e.g.,"PID:663"). Useful when multiple instances of the same app are running."AppName:WINDOW_TITLE:Title": Captures the window ofAppNamethat has the specifiedTitle(e.g.,"Notes:WINDOW_TITLE:My Important Note")."AppName:WINDOW_INDEX:Index": Captures the window ofAppNameat the specified zero-basedIndex(e.g.,"Preview:WINDOW_INDEX:0"for the frontmost window of Preview).
path(string, optional): Base absolute path for saving the captured image(s). Ifformatis"data"andpathis also provided, the image is saved to this path (as a PNG) AND Base64 data is returned. If aquestionis provided andpathis omitted, a temporary path is used for capture, and the file is deleted after analysis.question(string, optional): If provided, the captured image will be analyzed. The server automatically selects an AI provider from those configured in thePEEPIT_AI_PROVIDERSenvironment variable.format(string, optional, default:"png"): Specifies the output image format or data return type."png"or"jpg": Saves the image to the specifiedpathin the chosen format. For application captures: ifpathis not provided, behaves like"data". For screen captures: always saves to file."data": Returns Base64 encoded PNG data of the image directly in the MCP response. Ifpathis also specified, a PNG file is also saved to thatpath. Note: Screen captures cannot use this format and will automatically fall back to PNG file format.Invalid values (empty strings, null, or unrecognized formats) automatically fall back to
"png".
capture_focus(string, optional, default:"background"): Controls window focus behavior during capture."background": Captures without altering the current window focus (default)."foreground": Attempts to bring the target application/window to the foreground before capture. This might be necessary for certain applications or to ensure a specific window is captured if multiple are open.
Behavior with question (AI Analysis):
If a
questionis provided, the tool will capture the image (saving it topathif specified, or a temporary path otherwise).This image is then sent to an AI model for analysis. The AI provider and model are chosen automatically by the server based on your
PEEPIT_AI_PROVIDERSenvironment variable (trying them in order until one succeeds).The analysis result is returned as
analysis_textin the response. Image data (Base64) is NOT returned in thecontentarray when a question is asked.If a temporary path was used for the image, it's deleted after the analysis attempt.
Output Structure (Simplified):
content: Can containImageContentItem(ifformat: "data"orpathwas omitted, and noquestion) and/orTextContentItem(for summaries, analysis text, warnings).saved_files: Array of objects, each detailing a file saved topath(ifpathwas provided).analysis_text: Text from AI (ifquestionwas asked).model_used: AI model identifier (ifquestionwas asked).
For detailed parameter documentation, see docs/spec.md.
File Naming and Path Behavior
PeepIt intelligently manages output paths to prevent file overwrites while respecting your intentions:
Key Principle: Single vs Multiple Captures
When you provide a specific file path (e.g., ~/Desktop/screenshot.png), PeepIt determines whether to use it exactly or add metadata based on the capture context:
Single Capture → Exact Path
Capturing one specific window
Capturing one specific screen (when only one display exists)
Capturing with
app_target: "frontmost"Your path is used exactly as specified
Multiple Captures → Metadata Added
Capturing all windows of an app (
mode: "multi"or multiple windows exist)Capturing all screens (when multiple displays exist)
Capturing with no specific target (defaults to all screens)
Metadata is appended to prevent overwrites
Examples:
// SINGLE CAPTURES - Use exact path
// ================================
// One window of Safari
await use_mcp_tool("peepit", "image", {
app_target: "Safari",
path: "~/Desktop/browser.png"
});
// Result: ~/Desktop/browser.png ✓
// Specific screen (when you have only one monitor)
await use_mcp_tool("peepit", "image", {
app_target: "screen:0",
path: "~/Desktop/myscreen.png"
});
// Result: ~/Desktop/myscreen.png ✓
// Frontmost window
await use_mcp_tool("peepit", "image", {
app_target: "frontmost",
path: "~/Desktop/active.png"
});
// Result: ~/Desktop/active.png ✓
// MULTIPLE CAPTURES - Add metadata
// ================================
// All windows of Safari (mode: multi)
await use_mcp_tool("peepit", "image", {
app_target: "Safari",
mode: "multi",
path: "~/Desktop/browser.png"
});
// Results: ~/Desktop/browser_Safari_window_0_20250610_120000.png
// ~/Desktop/browser_Safari_window_1_20250610_120000.png
// All screens (multiple monitors)
await use_mcp_tool("peepit", "image", {
app_target: "screen", // or omit app_target
path: "~/Desktop/monitor.png"
});
// Results: ~/Desktop/monitor_1_20250610_120000.png
// ~/Desktop/monitor_2_20250610_120000.png
// DIRECTORY PATHS - Always use generated names
// ============================================
// Directory path (note trailing slash)
await use_mcp_tool("peepit", "image", {
app_target: "Safari",
path: "~/Desktop/screenshots/"
});
// Result: ~/Desktop/screenshots/Safari_20250610_120000.pngLong Filename Protection:
PeepIt automatically handles filesystem limitations:
Truncates filenames exceeding macOS's 255-byte limit
Preserves UTF-8 multibyte characters (emoji, non-Latin scripts)
Ensures metadata is always included when needed
Never creates invalid filenames
Example:
// Very long filename with emoji
await use_mcp_tool("peepit", "image", {
app_target: "Safari",
path: "~/Desktop/" + "🎯".repeat(100) + "_screenshot.png"
});
// Result: Filename safely truncated to fit 255-byte limit
// while preserving valid UTF-8 charactersFormat Validation:
Invalid formats ("bmp", "gif", "tiff", etc.) automatically convert to PNG
You'll receive a clear warning message when format correction occurs
Only "png" and "jpg"/"jpeg" are valid formats
Browser Helper Filtering:
PeepIt automatically filters out browser helper processes when searching for common browsers (Chrome, Safari, Firefox, Edge, Brave, Arc, Opera). This prevents confusing errors when helper processes like "Google Chrome Helper (Renderer)" are matched instead of the main browser application.
Examples:
// ✅ Finds main Chrome browser, not helpers
await use_mcp_tool("peepit", "image", {
app_target: "Chrome"
});
// ❌ Old behavior: Could match "Google Chrome Helper (Renderer)"
// Result: "no capturable windows were found"
// ✅ New behavior: Finds "Google Chrome" or shows "Chrome browser is not running"Browser-Specific Error Messages:
Instead of generic "Application not found"
Shows clear messages like "Chrome browser is not running or not found"
Only applies to browser identifiers - other apps work normally
Technical Features
Multi-display support: Each monitor gets its own moment in the spotlight
Smart app targeting: Fuzzy matching for app names
Multiple formats: PNG, JPEG, WebP, HEIF
Automatic naming: Timestamp-based, no overwrites
Permission checking: No surprises
Application listing: See what's running
Window enumeration: List all windows for an app
PID targeting: For the process-obsessed
Status monitoring: Know what's active
Provider agnostic: Ollama, OpenAI, and soon Anthropic
Natural language: Ask questions about images
Configurable: Environment-based
Fallback support: Automatic failover between providers
Architecture
PeepIt/
├── src/ # Node.js MCP Server (TypeScript)
│ ├── index.ts # Main MCP server entry point
│ ├── tools/ # Individual tool implementations
│ │ ├── image.ts # Screen capture tool
│ │ ├── analyze.ts # AI analysis tool
│ │ └── list.ts # Application/window listing
│ ├── utils/ # Utility modules
│ │ ├── peepit-cli.ts # Swift CLI integration
│ │ ├── ai-providers.ts # AI provider management
│ │ └── server-status.ts # Server status utilities
│ └── types/ # Shared type definitions
├── peepit-cli/ # Native Swift CLI
│ └── Sources/peepit/ # Swift source files
│ ├── main.swift # CLI entry point
│ ├── ImageCommand.swift # Image capture implementation
│ ├── ListCommand.swift # Application listing
│ ├── Models.swift # Data structures
│ ├── ApplicationFinder.swift # App discovery logic
│ ├── WindowManager.swift # Window management
│ ├── PermissionsChecker.swift # macOS permissions
│ └── JSONOutput.swift # JSON response formatting
├── package.json # Node.js dependencies
├── tsconfig.json # TypeScript configuration
└── README.md # This fileTechnical Details
JSON Output Format
The Swift CLI outputs structured JSON when called with --json-output:
{
"success": true,
"data": {
"applications": [
{
"app_name": "Safari",
"bundle_id": "com.apple.Safari",
"pid": 1234,
"is_active": true,
"window_count": 2
}
]
},
"debug_logs": ["Found 50 applications"]
}MCP Integration
The Node.js server provides:
Schema validation via Zod
Proper MCP error codes
Structured logging via Pino
Full TypeScript type safety
Security
PeepIt respects macOS security:
Checks permissions before operations
Graceful handling of missing permissions
Clear guidance for permission setup
Development
Testing Commands
./peepit list apps --json-output | head -20
echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}' | node dist/index.jsBuilding
npm run build
cd peepit-cli && swift buildKnown Issues
FileHandle warning: Non-critical Swift warning about TextOutputStream conformance
AI Provider Config: Requires
PEEPIT_AI_PROVIDERSenvironment variable for analysis features
License
MIT License - see LICENSE file for details.
Contributing
Fork the repo
Create a feature branch (
git checkout -b feature/amazing-feature)Commit your changes (
git commit -m 'Add amazing feature')Push to the branch (
git push origin feature/amazing-feature)Open a Pull Request
Author
Created by Peter Steinberger - @mantisware
Read more about PeepIt's design and implementation in the blog post.
Available Tools
3 toolsanalyzeA
Analyzes a pre-existing image file from the local filesystem using a configured AI model.
This tool is useful when an image already exists (e.g., previously captured, downloaded, or generated) and you need to understand its content, extract text, or answer specific questions about it.
Capabilities:
Image Understanding: Provide any question about the image (e.g., "What objects are in this picture?", "Describe the scene.", "Is there a red car?").
Text Extraction (OCR): Ask the AI to extract text from the image (e.g., "What text is visible in this screenshot?").
Flexible AI Configuration: Can use server-default AI providers/models or specify a particular one per call via 'provider_config'.
Example: If you have an image '/tmp/chart.png' showing a bar chart, you could ask: { "image_path": "/tmp/chart.png", "question": "Which category has the highest value in this bar chart?" } The AI will analyze the image and attempt to answer your question based on its visual content. PeepIt MCP 1.0.0-beta.1 using openai/gpt-4o, ollama/llava:latest
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | No | Required. Absolute path to image file (.png, .jpg, .webp) to be analyzed. | |
| question | Yes | Required. Question for the AI about the image. | |
| provider_config | No | Optional. Explicit provider/model. Validated against server's PEEPIT_AI_PROVIDERS. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool analyzes local image files, supports both image understanding and OCR capabilities, allows flexible AI configuration, and provides examples of how it responds. It mentions server configuration dependencies but doesn't cover error handling, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, usage context, capabilities list, and example. While comprehensive, it could be slightly more concise - the capabilities section repeats information from the purpose statement, and the example is detailed but necessary. Most sentences earn their place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description provides substantial context about what the tool does and how to use it. It covers purpose, usage guidelines, capabilities, and provides a concrete example. The main gap is the lack of information about return values or error conditions, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds minimal additional parameter semantics beyond what's in the schema - it mentions the types of questions that can be asked and provides an example, but doesn't add significant meaning beyond the comprehensive schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing pre-existing image files using AI models. It specifies the exact action ('analyzes'), resource ('image file from local filesystem'), and scope ('using configured AI model'). It distinguishes from sibling tools 'image' and 'list' by focusing on analysis rather than image manipulation or listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'when an image already exists (e.g., previously captured, downloaded, or generated) and you need to understand its content, extract text, or answer specific questions about it.' It also distinguishes capabilities (image understanding, OCR) and provides clear examples of appropriate use cases, making it easy to determine when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
imageA
Captures macOS screen content and optionally analyzes it. Targets can be entire screen, specific app window, or all windows of an app (via app_target). Supports foreground/background capture. Output via file path or inline Base64 data (format: "data"). If a question is provided, image is analyzed by an AI model (auto-selected from PEEPIT_AI_PROVIDERS). Window shadows/frames excluded. PeepIt MCP 1.0.0-beta.1 using openai/gpt-4o, ollama/llava:latest
| Name | Required | Description | Default |
|---|---|---|---|
| app_target | No | Optional. Specifies the capture target. For example: Omit or use an empty string (e.g., `''`) for all screens. Use `'screen:INDEX'` (e.g., `'screen:0'`) for a specific display. Use `'frontmost'` for all windows of the current foreground application. Use `'AppName'` (e.g., `'Safari'`) for all windows of that application. Use `'PID:PROCESS_ID'` (e.g., `'PID:663'`) to target a specific process by its PID. Use `'AppName:WINDOW_TITLE:Title'` (e.g., `'TextEdit:WINDOW_TITLE:My Notes'`) for a window of 'AppName' matching that title. Use `'AppName:WINDOW_INDEX:Index'` (e.g., `'Preview:WINDOW_INDEX:0'`) for a window of 'AppName' at that index. Ensure components are correctly colon-separated. | |
| path | Yes | Optional. Base absolute path for saving the image. Relevant if `format` is `'png'`, `'jpg'`, or if `'data'` is used with the intention to also save the file. If a `question` is provided and `path` is omitted, a temporary path is used for image capture, and this temporary file is deleted after analysis. | |
| question | No | Optional. If provided, the captured image will be analyzed by an AI model. The server automatically selects an AI provider from the `PEEPIT_AI_PROVIDERS` environment variable. The analysis result (text) is included in the response. | |
| format | Yes | Optional. Output format. Can be `'png'`, `'jpg'`, `'jpeg'` (alias for jpg), or `'data'`. Format is case-insensitive (e.g., 'PNG', 'Png', 'png' are all valid). If `'png'` or `'jpg'`, saves the image to the specified `path`. If `'data'`, returns Base64 encoded PNG data inline in the response. If `path` is also provided when `format` is `'data'`, the image is saved (as PNG) AND Base64 data is returned. Defaults to `'data'` if `path` is not given. Invalid format values automatically fall back to 'png'. | |
| capture_focus | No | Optional. Focus behavior. 'auto' (default): bring target to front only if not already active. 'background': capture without altering window focus. 'foreground': always bring target to front before capture. | auto |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing key behaviors: window shadows/frames are excluded, output can be via file path or Base64 data, AI analysis occurs when a question is provided using auto-selected providers, and temporary files are deleted after analysis. The only minor gap is lack of explicit mention about permissions needed for screen capture or potential rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. It efficiently covers capture targets, output formats, and analysis capability in a few sentences. The version information at the end ('PeepIt MCP 1.0.0-beta.1...') could be considered extraneous but doesn't significantly detract from the overall conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and no output schema, the description provides substantial context about behavior, use cases, and parameter interactions. It covers the dual functionality (capture + optional analysis) well. The main gap is the lack of information about return values or response structure, which would be important since there's no output schema. However, the description compensates well for the missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description mentions some parameters (app_target, format, question) but doesn't add significant semantic value beyond what's in the schema. It provides context about how parameters interact (e.g., path behavior with format='data'), but the schema already covers most of this. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Captures macOS screen content and optionally analyzes it.' It specifies the verb ('captures'), resource ('macOS screen content'), and optional analysis capability. It distinguishes from sibling tools 'analyze' and 'list' by focusing on capture functionality with optional analysis, rather than pure analysis or listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: for screen capture with optional AI analysis. It mentions specific use cases like targeting entire screens, app windows, or all windows of an app. However, it doesn't explicitly state when NOT to use this tool or when to prefer sibling tools like 'analyze' (which might be for analyzing existing images rather than capturing new ones).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listA
Lists various system items on macOS, providing situational awareness.
Capabilities:
Running Applications: Get a list of all currently running applications (names and bundle IDs).
Application Windows: For a specific application (identified by name or bundle ID), list its open windows.
Details: Optionally include window IDs, bounds (position and size), and whether a window is off-screen.
Multi-window apps: Clearly lists each window of the target app.
Server Status: Provides information about the PeepIt MCP server itself (version, configured AI providers).
Use Cases:
Agent needs to know if 'Photoshop' is running before attempting to automate it. { "item_type": "running_applications" } // Agent checks if 'Photoshop' is in the list.
Agent wants to find a specific 'Notes' window to capture. { "item_type": "application_windows", "app": "Notes", "include_window_details": ["ids", "bounds"] } The agent can then use the window title or ID with the 'image' tool. PeepIt MCP 1.0.0-beta.1 using openai/gpt-4o, ollama/llava:latest
| Name | Required | Description | Default |
|---|---|---|---|
| item_type | Yes | Specifies the type of items to list. If omitted or empty, it defaults to 'application_windows' if 'app' is provided, otherwise 'running_applications'. Valid options are: - `running_applications`: Lists all currently running applications. - `application_windows`: Lists open windows for a specific application. Requires the `app` parameter. - `server_status`: Returns information about the PeepIt MCP server. | |
| app | No | Required when `item_type` is `application_windows`. Specifies the target application by its name (e.g., "Safari", "TextEdit"), bundle ID, or process ID (e.g., "PID:663"). Fuzzy matching is used for names, so partial names may work. | |
| include_window_details | Yes | Optional, only applicable when `item_type` is `application_windows`. Specifies additional details to include for each window. Provide an array of strings. Example: `["bounds", "ids"]`. - `ids`: Include window ID. - `bounds`: Include window position and size (x, y, width, height). - `off_screen`: Indicate if the window is currently off-screen. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by describing capabilities, details available for windows (IDs, bounds, off-screen status), and server information. However, it doesn't mention performance characteristics, rate limits, or potential side effects of listing operations. The description is informative but could be more comprehensive about behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Capabilities, Use Cases) and uses bullet points effectively. However, it includes version information ('PeepIt MCP 1.0.0-beta.1 using openai/gpt-4o, ollama/llava:latest') that doesn't add value for tool selection. The core content is front-loaded and efficient, but could be slightly more concise by removing the version details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains what the tool does, when to use it, and provides concrete examples. However, without an output schema, the description could better explain what information is returned for each item_type, particularly for server_status which is mentioned but not detailed in the examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context about fuzzy matching for app names and provides concrete examples of parameter usage, but doesn't add significant semantic meaning beyond what's already in the schema descriptions. The baseline of 3 is appropriate given the comprehensive schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Lists various system items on macOS, providing situational awareness' and specifies three distinct capabilities: listing running applications, application windows, and server status. It distinguishes itself from sibling tools 'analyze' and 'image' by focusing on listing rather than analysis or image capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines through 'Use Cases' section with concrete examples showing when to use each item_type. It distinguishes between different scenarios: checking if an app is running, finding specific windows for capture, and getting server status. The examples clearly demonstrate appropriate parameter configurations for each use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v1.0.0- First observed
analyze - First observed
image - First observed
list
TDQS
The three tools have clearly distinct purposes with no overlap: 'analyze' processes existing image files, 'image' captures macOS screens and optionally analyzes them, and 'list' provides system information. Each tool targets a different primary function (file analysis, screen capture, system listing), making them easily distinguishable.
All tool names follow a consistent, simple verb-based pattern: 'analyze', 'image', and 'list'. While 'image' is a noun rather than a verb, it functions as a clear action (capture image) and maintains a uniform, concise naming style across the set without mixing conventions.
With only 3 tools, the count is well-scoped for the server's purpose of macOS screen interaction and analysis. Each tool serves a distinct, essential function: listing system items for awareness, capturing screens, and analyzing images, covering the core workflow without unnecessary bloat.
The tool set covers the primary workflows for macOS screen automation: listing applications/windows, capturing screens, and analyzing images. A minor gap exists in lacking tools for direct interaction with windows (e.g., focus, resize) or file management, but agents can work around this using the provided tools for basic automation tasks.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Generate images, GIFs, and PDFs from HTML, URLs, or templates — from your AI agent.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Screenshots, PDFs and Markdown from any URL or HTML for AI agents, via the SnapForge API
Related MCP Servers
- AlicenseAqualityAmaintenanceA macOS utility that captures screenshots and analyzes them with AI vision, enabling AI assistants to see and interpret what's on your screen.38035,077MIT
- AlicenseNot gradedqualityNot gradedmaintenanceEnables LLMs to capture and analyze screenshots of your screen, windows, or regions with smart detection capabilities. Features natural language queries, automatic window targeting, and text enhancement for UI debugging and visual inspection.2-
- AlicenseDqualityDmaintenanceEnables AI assistants to capture and analyze screenshots using Claude Vision API, providing AI-powered insights about desktop interface content, UI elements, and visual layouts.2822MIT
- AlicenseNot gradedqualityCmaintenanceEnables screenshot capture and visual analysis using cloud or local vision models, with tools to describe screens, list windows, and analyze images.11914MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MantisWare/peepit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server