Screenshot API for AI agents. Any public page as image or PDF, banners hidden, 227 countries.
Scored across 3 tools
The three tools target clearly distinct actions: informational pricing, a static country list, and a single demo screenshot. There is no overlap or risk of misselection between them.
All three names follow a consistent verb_noun pattern (get_pricing, list_countries, take_demo_screenshot) with distinct, sensible verbs. No deviations or mixed conventions.
Three tools is thin for a screenshot service, and the descriptions themselves note the real capture capability lives on a different server. It is borderline sparse rather than clearly wrong.
The primary operation—capturing a screenshot of a user-chosen page—is entirely absent, only a fixed demo is offered. Pricing and country listing exist, but the core value/workflow is a dead end that forces users to another server.
What localscreenshot costs: the free credits every account gets each month, the limits of a free account, what a screenshot costs in credits, and where paid plans and credit packs start.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| currency | Yes | Currency of the prices, ISO 4217. |
| countries | Yes | Number of countries a screenshot can be taken from. |
| packs_from | Yes | |
| plans_from | Yes | |
| free_credits | Yes | Free credits an account without a paid plan gets each calendar month (UTC). They do not carry over. |
| free_credits_period | Yes | How often the free credits come back: "month". |
| credits_per_screenshot | Yes | Credits one screenshot costs. |
| free_requests_per_minute | Yes | Requests a minute for an account that has only free credits. |
| credits_per_screenshot_with_country | Yes | Credits one screenshot costs when a country is chosen. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful content-level transparency by listing which pricing facts are returned. It does not state staleness/freshness of the pricing data or currency assumptions, so it adds some value but stops short of rich behavioral context.
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?
A single colon-delimited sentence with the key scope ('what localscreenshot costs') front-loaded and each listed item earning its place by telling the agent exactly what facts come back. Zero filler.
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?
An output schema exists, so the description need not explain the return structure, and it appropriately focuses on what categories of pricing information are covered. Minor gap: no note about data freshness or currency, which an agent answering cost questions might want. Otherwise complete for a no-param read 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?
The tool takes zero parameters, which sets a baseline of 4 per the rubric — there is nothing for the description to disambiguate. The schema description coverage is 100% and empty, so no compensation is required.
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 names a specific resource ('what localscreenshot costs') and enumerates the exact facets returned: free monthly credits, free-account limits, per-screenshot credit cost, and where paid plans/credit packs start. This is far beyond a tautology of the name/title. It does not explicitly compare itself to siblings, but list_countries and take_demo_screenshot are clearly unrelated, so differentiation is implicit rather than stated.
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 is implied by the content (this is the tool to consult for cost/credit questions) but there is no explicit when-to-use statement, no alternatives named, and no exclusions. For a zero-parameter informational lookup the alternative space is nearly empty, which caps the practical need but the description still says nothing about when this should be preferred over, say, surfacing pricing from product docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the countries a screenshot can be taken from, with their two-letter codes. Choosing a country needs an account: this free endpoint only lists them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of countries. |
| countries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive and non-open-world behavior. The description adds real context beyond them: the endpoint is free and only enumerates options, and consuming a country requires an account, which tells the agent about a downstream constraint.
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 short sentences, front-loaded with what the tool returns, followed by the account constraint. No filler or restatement of the name/title.
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?
An output schema exists, so return format need not be explained. The description covers scope and the account limitation adequately for such a simple no-parameter tool, though it says nothing about ordering or filtering behavior.
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?
There are zero parameters, so the schema carries no semantics to explain; the description correctly adds no parameter prose. It notes the two-letter code shape of the output, which is minor added value.
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?
Specific verb 'List' plus resource 'countries a screenshot can be taken from' with the added detail of two-letter codes. It is clearly distinguishable from siblings like take_demo_screenshot and get_pricing, which perform different actions.
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 states this is the free listing endpoint and that actually choosing a country requires an account, which frames when this tool applies rather than the account-bound path. It does not name a specific alternative tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See what a localscreenshot result looks like: a real screenshot of one of our example pages. It does not capture a page of your choice. For that, create a free account and use the main MCP server with an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | Which example page to capture. | |
| device | No | Screen to render it on. Default: desktop. |
| Name | Required | Description |
|---|---|---|
| page | No | Site that was captured. |
| width | No | Image width in pixels. |
| height | No | Image height in pixels. |
| status | Yes | "succeeded" when the image is ready, "pending" while it is being taken. |
| taken_at | No | When the screenshot was taken. Example pages are shared and can be a few hours old. |
| image_url | No | Short-lived link to the image. |
| page_status | No | HTTP status the page answered with. |
| retry_after_seconds | No | When pending: how long to wait before calling again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a read-only, non-destructive, open-world operation. The description adds meaningful context beyond that: it only ever captures a fixed set of example pages and requires a separate account/API key to capture arbitrary URLs. It does not add rate-limit or auth-specific detail, but the key behavioral constraint is disclosed.
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 tight sentences with the purpose front-loaded and the limitation following immediately; nothing is wasted. The phrasing 'localscreenshot result' is slightly awkward, keeping it just short of ideal.
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?
With an output schema present and full param coverage, the description doesn't need to explain returns or parameters. It covers the essential scope constraint and the redirect to the real service. Sufficient, though a line naming the three available example pages would have eliminated any residual guesswork.
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% and both parameters are enums with documented options, so the schema fully carries parameter meaning. The description adds no parameter detail (it doesn't even mention that only three example pages exist), which is acceptable at this coverage level but earns only the baseline.
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 conveys that this returns a sample/preview screenshot of a fixed example page ('a real screenshot of one of our example pages'), which is a specific verb+resource. It also immediately clarifies the scope limitation. It does not differentiate against its siblings (get_pricing, list_countries), but those appear unrelated to screenshotting.
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?
It explicitly states the negative case — 'It does not capture a page of your choice' — and names the alternative path: create an account and use the main MCP server with an API key. An agent knows exactly when this tool is and isn't appropriate.
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.
get_pricinglist_countriestake_demo_screenshotScreenshot, PDF and Open Graph image API for AI agents: capture pages, render PDFs, make OG images.
Screenshot any public web page from an AI agent. Free without signup, or with an API key.
Bulk website screenshots and PDFs with cookie banners removed; also a real-time HTTP API (Standby).
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Add one secure layer between your agents and this server.
