Click on "Deploy 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., "@Open Eagle Eye get a snapshot from a traffic camera in New York"
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.
MCP server that gives AI agents instant access to public camera feeds worldwide. One HTTP GET, sub-second captures, no browser automation, no stream decoding.
Most camera APIs require authentication, serve video streams, or hide images behind JavaScript rendering. Open Eagle Eye only indexes cameras that return a JPEG or PNG on a plain HTTP GET — the simplest possible integration. Agents don't need to render pages or decode video. They just fetch an image.
The registry is self-healing. A GitHub Action runs nightly, checks every camera, retries failures before removing them, and uses vision AI to catch cameras that return error pages instead of live feeds. Dead cameras get flagged automatically.
Related MCP server: camera-mcp
{
"mcpServers": {
"openeagleeye": {
"command": "npx",
"args": ["-y", "openeagleeye"]
}
}
}Or install globally:
npm install -g openeagleeye
openeagleeyeOn first run, the server fetches the latest camera registry from GitHub and caches it locally in ~/.openeagleeye/. Subsequent starts refresh the cache automatically.
A valid camera URL is any endpoint that returns a JPEG or PNG on a plain HTTP GET. Most city traffic cameras, weather stations, and park cams expose exactly this. The server fetches the image, saves it to disk, and returns the file path.
Tool | Description |
| Fetch a live image from a camera — saves to disk, returns file path |
| Browse the registry with filters (city, location, category) |
| Search by name, location, or category |
| Add a camera to your local collection |
| Show your locally-added cameras |
| Delete a locally-added camera |
| Share local cameras upstream via GitHub issue |
| Report a broken or low-quality camera |
| Show API key configuration status |
The registry has two layers:
Upstream — the global registry fetched from GitHub on every server start. These are the ~32,000 validated public cameras.
Local — cameras you add yourself via add_local_camera. They persist in ~/.openeagleeye/local-cameras.json, survive restarts, and appear in list_cameras/search_cameras with source: "local". Share them upstream anytime with submit_local.
Every camera has a city field. Use list_cameras with city: "Sydney" to get a short, focused list instead of dumping all cameras into context.
Every tool returns structured JSON. Snapshots save to disk and return the file path — the MCP server runs as a local subprocess, so the agent has filesystem access.
Snapshot response:
{
"success": true,
"file_path": "/home/user/.openeagleeye/snapshots/a1b2c3d4e5f6a7b8.jpg",
"size_bytes": 14579,
"content_type": "image/jpeg",
"camera": {
"id": "nyc-bb-21-north-rdwy-at-above-south-st",
"name": "BB-21 North Rdwy @ Above South St",
"city": "New York",
"location": "Manhattan, New York, USA",
"coordinates": { "lat": 40.708, "lng": -73.999 }
}
}~32,000 cameras across eleven countries (32,096 verified):
Country | Count | Sources |
US | 27,184 | NYC DOT, NY 511, WSDOT, Caltrans CWWP2, CDOT CoTrip, VDOT 511, FDOT FL511, NCDOT, PennDOT 511PA, Arizona ADOT, Oregon ODOT, Nevada NDOT, Utah UDOT, Wisconsin WisDOT, New England 511, Louisiana LADOTD, Alaska DOT&PF, Missouri MoDOT |
FI | 1,309 | Digitraffic weather cameras (Fintraffic) |
CA | 1,292 | Ontario MTO, Alberta 511 |
HK | 995 | Hong Kong Transport Department |
GB | 424 | London TfL JamCams |
NZ | 248 | NZTA nationwide highways |
AU | 247 | Queensland DOT traffic + flood cameras |
BR | 160 | CET São Paulo urban traffic |
JP | 98 | NEXCO East expressways |
SG | 90 | Singapore LTA |
IE | 49 | TII motorway cams (M50 Dublin) |
Every camera has country, city, location, timezone, and coordinates (lat/lng).
A GitHub Action runs nightly at 3 AM UTC:
Checks cameras not validated in the last 7 days, plus any flagged as suspect
First failure marks as suspect, second consecutive failure removes and opens a GitHub issue
Vision AI (GPT-4o-mini via GitHub Models) catches cameras returning error pages
Suspect cameras that recover are cleared automatically
SSRF protection — blocks private IPs, cloud metadata endpoints, non-HTTP protocols, and DNS rebinding
Content-type whitelist — only image/jpeg and image/png accepted
Magic byte detection — validates JPEG/PNG by file header when CDN returns wrong content-type
Push/PR cap — max 500 cameras per push to prevent DoS via oversized PRs
Random filenames — snapshots use random hex filenames, no camera ID in the path
Most cameras work out of the box. Some require a free API key. If a snapshot fails with a key error, the response tells you where to sign up and how to configure it.
Create ~/.openeagleeye/config.json:
{
"api_keys": {
"PROVIDER_API_KEY": "your-key-here"
}
}Use check_config to see which cameras need keys and whether yours are set.
Find a direct-image URL (must return image/jpeg or image/png on plain GET)
add_local_camera with the URL, city, location, timezone, and optional coordinates
get_snapshot to test it
submit_local to share upstream — requires the gh CLI (gh auth login)
Local cameras work immediately and don't need upstream approval to be useful.
Good sources: city DOTs, weather stations, ski resorts, national parks, ports, airports.
All runtime data lives in ~/.openeagleeye/:
~/.openeagleeye/
cameras.json # Upstream registry (fetched from GitHub on boot)
local-cameras.json # Your locally-added cameras
.registry-state.json # Validation state (active/suspect/offline)
snapshots/ # Downloaded camera images
config.json # API keysPull requests welcome. See CONTRIBUTING.md for guidelines on adding camera sources.
See WHY.md for the reasoning behind the project's design decisions, how it compares to other camera services, and why agent-native and self-healing matter.
See SECURITY.md for answers to common questions about surveillance, data collection, private cameras, and the security architecture.
MIT
Add a camera to your local collection. Local cameras persist in ~/.openeagleeye/local-cameras.json and survive restarts and registry updates. They appear in list_cameras and search_cameras with source 'local'. Share upstream anytime with submit_local.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable camera name | |
| url | Yes | Direct image URL — must return JPEG or PNG on HTTP GET | |
| city | Yes | City name (e.g. 'London', 'New York', 'Sydney') | |
| location | Yes | Location description (e.g. 'Manhattan, New York, USA') | |
| timezone | Yes | IANA timezone (e.g. 'America/New_York', 'Europe/London') | |
| category | No | Camera category | |
| lat | No | Latitude of the camera | |
| lng | No | Longitude of the camera | |
| auth_provider | No | Provider name if API key is needed (e.g. 'Transport for London') | |
| auth_signup_url | No | URL to register for API key | |
| auth_key_required | No | Whether the image URL requires an API key at fetch time | |
| auth_key_type | No | How to inject the key | |
| auth_key_names | No | Query param or header names for the key | |
| auth_config_key | No | Key name to use in ~/.openeagleeye/config.json | |
| auth_note | No | Notes about authentication |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions persistence file and source label, but does not cover error scenarios like duplicate names or invalid URLs. Adequate but not thorough.
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?
Three sentences, all substantive and front-loaded with the core action. No filler or redundancy.
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?
Given 15 parameters and no output schema, the description is adequate but missing return value information. It explains persistence and source but could detail what the tool returns (e.g., success or camera ID).
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 coverage is 100% with clear descriptions for all 15 parameters. The description adds no extra parameter detail; it notes category but not enum values. Meets baseline for high 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 explicitly states 'Add a camera to your local collection' with a specific verb and resource. It distinguishes from siblings like remove_local by detailing persistence and source.
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?
Provides clear context on when to use (adding persistent local cameras), describes behavior (survives restarts, appears with source 'local'), and references sibling tool submit_local for sharing. Does not explicitly state when not to use, but guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show API key configuration status. Lists all cameras in the registry that require authentication, the provider name, whether a key is configured in ~/.openeagleeye/config.json, and the signup URL for each. Use when a snapshot fails with an API key error to see which keys are missing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses that it lists cameras requiring auth, provider, key config, and signup URL, implying read-only behavior. No contradictions.
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?
Three sentences with no waste. First sentence states purpose, second adds detail, third gives usage context. Highly concise and front-loaded.
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 zero-parameter, no-output-schema diagnostic tool, the description is complete. It tells what it shows and when to use it. No gaps given the tool's simplicity.
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?
Input schema has zero parameters, so schema coverage is 100%. With no parameters, no additional semantic information is needed. Baseline 4 is appropriate.
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 it shows API key configuration status, listing cameras needing authentication, provider, key config, and signup URL. This distinguishes it from sibling tools like list_cameras and get_camera_info.
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?
Explicitly states when to use: 'Use when a snapshot fails with an API key error to see which keys are missing.' Provides clear context with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get random cameras from the registry for discovery. Returns a surprise selection. Filter by city, country, or category to narrow the pool, or leave empty for a truly random pick.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Filter pool to this city (e.g. 'Tokyo', 'Paris') | |
| country | No | Filter pool to this country (e.g. 'JP', 'France') | |
| category | No | Filter by category: city, park, highway, airport, port, weather, nature, landmark, other | |
| count | No | How many random cameras to return (default 3, max 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions randomness and filtering, which is good, but does not disclose whether the operation is read-only, required authentication, or any side effects. Adequate but not fully transparent.
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?
Two sentences, front-loaded with the main purpose, no redundancy. Every word serves a purpose.
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?
The description covers the basic behavior but lacks details about return format (what fields are in the 'surprise selection'), pagination, or default count. With no output schema, more completeness would be beneficial.
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 description adds little new meaning. It reinforces the filtering concept but does not provide deeper semantics beyond what the schema already offers. Baseline 3 is appropriate.
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 uses a specific verb ('Get') and resource ('random cameras from the registry') and clearly states the purpose ('for discovery'). It distinguishes itself from sibling tools like list_cameras or search_cameras by emphasizing randomness.
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 explains when to filter (city, country, category) and when to leave empty for random selection. It does not explicitly list alternatives or exclusions, but the context is clear enough for most discovery scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up camera metadata by ID. Returns full details for a single camera without fetching a snapshot. Use this to check if an ID is valid or to get current metadata for a known camera.
| Name | Required | Description | Default |
|---|---|---|---|
| cam_id | Yes | Camera ID to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it returns full details without fetching a snapshot, a key behavioral trait. No annotations exist, so the description carries the full burden; it adequately covers the safety profile for a read-only lookup.
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?
Two sentences, no wasted words; each sentence provides essential information.
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?
Given the single parameter, lack of output schema, and no annotations, the description is fully adequate—it explains what the tool does, when to use it, and what it returns.
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?
The schema already describes 'cam_id' well (100% coverage), but the description adds context about using it to validate an ID or get metadata, enhancing parameter meaning.
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 it looks up camera metadata by ID, returning full details for a single camera without a snapshot, distinguishing it from siblings like get_snapshot and list_cameras.
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?
Explicitly says 'Use this to check if an ID is valid or to get current metadata for a known camera,' providing clear context. However, it does not mention when not to use it or exhaustively list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a live image from a camera. Downloads the image to disk and returns the file path. Works on both upstream registry cameras and locally-added cameras. Use list_cameras or search_cameras first to find IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| cam_id | Yes | Camera ID (from list_cameras/search_cameras), or a direct image URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses main behavior (downloads to disk, returns file path) but lacks details on side effects (e.g., disk usage, overwrite behavior) or authentication requirements. With no annotations, description carries full burden; it is adequate but not thorough.
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?
Three concise sentences: purpose, behavior/result, and usage context. Front-loaded and no unnecessary words.
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?
Covers core functionality, supported camera types, and prerequisite steps. Slightly incomplete as it doesn't describe return format details (e.g., file path format) but acceptable given no 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 already fully describes the parameter (cam_id as ID or URL). Description adds no additional param semantics; baseline 3 due to 100% 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?
Description clearly states 'Fetch a live image from a camera' and specifies the output (file path). However, it does not differentiate from sibling 'get_snapshots' (plural), which may cause confusion.
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?
Provides context on which cameras it works with (upstream and locally-added) and recommends using list_cameras/search_cameras first. Does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch live images from multiple cameras in one call. Returns all snapshot file paths. Use to compare several cameras at once or to monitor a set of favorites. Max 5 cameras per call.
| Name | Required | Description | Default |
|---|---|---|---|
| cam_ids | Yes | Array of camera IDs (from list_cameras/search_cameras). Max 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses read-only nature ('Fetch live images'), return format ('Returns all snapshot file paths'), and limit ('Max 5'). Lacks info on authorization or side effects, but adequate for a simple read tool.
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?
Three concise sentences, front-loaded with purpose, no redundant words.
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?
Tool is simple (1 param, no output schema). Description explains action, return, and constraint. Could mention read-only nature more explicitly, but complete enough for expected use.
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 coverage is 100% and describes cam_ids well. Description reiterates the limit and purpose, adding marginal value beyond schema. Baseline 3 is appropriate.
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?
Clearly states 'Fetch live images from multiple cameras' with specific action and resource, distinguishing from siblings like get_snapshot (single camera) and search_cameras (search).
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?
Provides context: 'Use to compare several cameras at once or to monitor a set of favorites.' Does not explicitly exclude single-camera use, but sibling names imply alternative. Constraint 'Max 5 cameras per call' is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the camera registry. Returns cameras with id, name, city, country, location, category, coordinates, and source (upstream or local). Supports filtering by city, country, location, and category. Use limit/offset for pagination — the full registry is large.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Filter by city name (e.g. 'London', 'New York', 'Sydney') | |
| country | No | Filter by country code or name (e.g. 'US', 'UK', 'Australia', 'JP') | |
| location | No | Filter by location string (e.g. 'Manhattan', 'Borough') | |
| category | No | Filter by category: city, park, highway, airport, port, weather, nature, landmark, other | |
| limit | No | Max cameras to return (default 20, max 100) | |
| offset | No | Skip this many cameras (for pagination, default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's read-only behavior, return fields, filtering capabilities, and pagination need. It adds value by noting the registry is large. No behavioral surprises or contradictions.
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 concise (two sentences plus a pagination note) and front-loaded with the primary purpose. Every sentence adds value, with no redundancy or fluff.
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?
Despite no output schema, the description explicitly lists the fields returned, which is sufficient for a listing tool. The filtering and pagination details make it complete for the agent to use correctly.
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 coverage is 100% with good parameter descriptions. The description adds context about pagination (limit/offset) and emphasizes that the registry is large, which helps the agent decide how to use parameters effectively.
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: 'Browse the camera registry' and lists the fields returned. It distinguishes itself from siblings like 'search_cameras' but does not explicitly contrast with other browse tools such as 'explore_cameras' or 'list_local'.
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 mentions filtering and pagination, giving usage context. However, it lacks explicit when-to-use or when-not-to-use guidance compared to sibling tools, and does not provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show your locally-added cameras. These persist in ~/.openeagleeye/local-cameras.json and survive restarts and registry updates. They appear in list_cameras and search_cameras with source 'local'. Returns camera IDs, names, URLs, coordinates, and auth requirements.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description clearly indicates read-only operation, persistence in ~/.openeagleeye/local-cameras.json, and survival across restarts. Could mention if any side effects exist, but likely none.
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?
Two concise sentences that efficiently convey purpose, persistence, and output. No wasted words.
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?
Given no parameters and no output schema, the description fully explains what the tool does, what it returns, and its relation to sibling tools (appears in list_cameras/search_cameras). Complete for a simple list tool.
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?
No parameters, so description adds no param details beyond schema. Baseline 4 per instructions for 0-param tools.
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?
Description clearly states it shows locally-added cameras, specifies persistence, and distinguishes from siblings like list_cameras by mentioning source 'local'.
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?
Usage context is implied (for viewing only local cameras) but no explicit when-to-use or when-not-to-use compared to alternatives like list_cameras.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find cameras within a geographic radius. Returns cameras sorted by distance from the given point. Use for spatial queries like 'webcams near Times Square' or 'cameras within 10km of the Opera House'.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude of the center point | |
| lng | Yes | Longitude of the center point | |
| radius_km | No | Search radius in kilometers (default 25, max 500) | |
| limit | No | Max results (default 10, max 50) | |
| category | No | Filter by category: city, park, highway, airport, port, weather, nature, landmark, other |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that results are sorted by distance, which is useful behavior. However, it does not mention side effects, authentication requirements, rate limits, or that it is read-only (implied but not explicit).
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?
Two sentences plus one example sentence. Front-loaded with purpose, then behavior, then usage. Every sentence earns its place; no wasted words.
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?
No output schema exists, but description only says 'Returns cameras sorted by distance'. It does not specify what fields are returned or pagination behavior. For a spatial query tool with 5 parameters, some details on return structure would improve completeness.
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 coverage is 100%, so parameters are well-documented in the schema. The description adds context about geographic radius and sorting, but this is largely implied by the parameter names and descriptions. Little additional value beyond the schema.
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?
Description clearly states the verb 'Find' and resource 'cameras within a geographic radius'. Examples like 'webcams near Times Square' reinforce the spatial query purpose, but it does not explicitly contrast with siblings like 'search_cameras' or 'explore_cameras'.
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?
Description says 'Use for spatial queries like...' which provides clear context for when to use this tool. It does not mention when not to use it or list alternatives, but the examples are specific and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a locally-added camera by ID. Removes it from ~/.openeagleeye/local-cameras.json and the in-memory merged view. The camera is also auto-removed from the merged list. Use after sharing upstream via submit_local, or when a URL stops working.
| Name | Required | Description | Default |
|---|---|---|---|
| cam_id | Yes | Local camera ID to remove (starts with 'local-') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses deletion from specific files and auto-removal from merged list. Missing details on reversibility or error states, but sufficient for a simple deletion tool.
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?
Three sentences, each adding value: action, file details, use cases. Front-loaded with the verb. No redundancy.
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?
Covers action, files affected, and usage timing. Missing return value or error handling, but no output schema expectations. Adequate for a straightforward delete tool.
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 already describes parameter fully (cam_id, required, format 'local-'). The description adds no new parameter info beyond reinforcing context. High schema coverage (100%) sets baseline at 3.
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 explicitly states the action (Delete), the resource (locally-added camera by ID), and the specific files modified (~/.openeagleeye/local-cameras.json and in-memory merged view). It distinguishes from sibling tools like add_local_camera (adds) and submit_local (shares upstream).
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?
Provides explicit when-to-use scenarios: 'Use after sharing upstream via submit_local, or when a URL stops working.' This gives clear context for invocation and implies when not to use (e.g., when camera is not local).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a broken or low-quality camera. Files a GitHub issue with a snapshot showing the current state, and saves the report locally. If the camera is local with a broken link, it is automatically removed. Requires 'gh' CLI for GitHub issue creation.
| Name | Required | Description | Default |
|---|---|---|---|
| cam_id | Yes | Camera ID to report | |
| status | Yes | Type of issue | |
| notes | No | Additional details about the issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses key behaviors: it files a GitHub issue, saves a report locally, and automatically removes local cameras with broken links. It also notes a dependency ('gh' CLI), providing full transparency.
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 two sentences with no wasted words. It front-loads the main action and follows with key details and requirements. Every sentence adds 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?
The description covers the main behaviors, conditions for auto-removal, and a dependency. It lacks information about the return value or confirmation, but given the tool's simplicity and no output schema, it is reasonably complete.
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?
All three parameters (cam_id, status, notes) have clear descriptions in the input schema (100% coverage). The description does not add additional meaning beyond the schema; it mentions a snapshot but that appears to be an automatic behavior not tied to a parameter. Baseline of 3 is appropriate.
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: reporting broken or low-quality cameras by filing a GitHub issue and saving locally. It distinguishes from siblings like get_camera_info or explore_cameras, which are about viewing or browsing, not reporting.
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 mentions the requirement for 'gh' CLI and implies the tool is for reporting camera issues (broken/low-quality). It does not explicitly state when not to use or suggest alternatives, but the context from sibling tools provides sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cameras by text. Matches against name, city, country, location, and category. Use when looking for cameras in a specific place or of a specific type.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term — matches camera name, city, country, location, and category | |
| limit | No | Max results to return (default 20, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether the operation is read-only, pagination behavior (though limit hint is in schema), or performance characteristics. A search tool should at least state it is read-only.
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 extremely concise: two sentences that front-load the purpose and usage. Every word adds value, and there is no fluff.
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 simple tool with only two parameters and no output schema, the description covers the core functionality and usage. It is slightly lacking in behavioral details (e.g., ordering of results, whether pagination is implicit), but overall it is adequate.
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 coverage is 100%, so the description adds no new meaning beyond the schema for both parameters. The description repeats the schema's information about matched fields without providing additional context like partial matching or case sensitivity.
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: 'Search cameras by text' and specifies the fields matched: name, city, country, location, and category. This distinguishes it from sibling tools like explore_cameras or list_cameras.
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 usage context: 'Use when looking for cameras in a specific place or of a specific type.' While it doesn't explicitly list when not to use it, the guidance is sufficient for an agent to differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Share your locally-added cameras with the upstream Open Eagle Eye registry by filing a GitHub issue. Validates each camera URL, checks for duplicates, and embeds a snapshot preview. Requires the 'gh' CLI installed and authenticated (gh auth login). Your local cameras are not removed — use remove_local after they are accepted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description bears full burden. Discloses validation, duplicate checking, snapshot preview, and that local cameras are not removed. Lacks details on error handling or duplicate resolution.
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?
Three sentences, each essential: main action, validation details, prerequisites, and side-effect clarification. No wasted words.
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?
Given zero parameters and no output schema, the description covers the action, prerequisites, and constraints. Could mention error handling or failure cases, but adequate for low complexity.
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?
No parameters in schema, baseline 4. Description effectively explains the tool's operation without needing parameters, as it acts on existing local cameras.
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 submits locally-added cameras to an upstream registry via a GitHub issue, and distinguishes from siblings like add_local_camera and remove_local.
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?
Provides explicit context: use after adding cameras locally, not for removal, and requires 'gh' CLI installed and authenticated. Mentions alternative tool remove_local for after acceptance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v8.0.0add_local_cameracheck_configexplore_camerasget_camera_infoget_snapshotget_snapshotslist_cameraslist_localnearby_camerasremove_localreport_camerasearch_camerassubmit_localScored across 13 tools
Each tool has a clearly distinct purpose: adding/removing local cameras, fetching snapshots, searching, browsing, exploring, reporting, etc. No two tools overlap in functionality.
Most tools follow a verb_noun pattern (e.g., add_local_camera, get_snapshot, list_cameras), but a few like 'explore_cameras' and 'nearby_cameras' deviate slightly. Overall, the naming is clear and intuitive.
13 tools appropriately cover the core operations of a camera registry: CRUD for local cameras, search/discovery, snapshots, and registry interaction. The count feels neither sparse nor overwhelming.
The tool set covers the full lifecycle: discovering upstream cameras, managing local ones (add, remove, submit), fetching snapshots individually or in batches, and reporting issues. No obvious gaps for the intended domain.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server for Wan AI video generation
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
