Skip to main content
Glama

Framejet Screenshot

by dev.framejet
OverviewDiscussionsAdmin

Server Details

Clean PNG/JPEG screenshots via REST or MCP, with goal-driven multi-step navigation.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
63.0% over 22 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of misselection between tools. An agent will always know that `screenshot` is the single entry point for rendering URLs.

Naming Consistency5/5

With a single tool named `screenshot`, there is no cross-tool naming inconsistency to worry about. The name is a clear, readable noun describing exactly what the tool returns.

Tool Count3/5

A one-tool surface is borderline thin even for a focused rendering service; the description hints at several distinct modes (raw URL capture, goal-driven flows, deterministic actions) that could have been separate operations. It is coherent as-is, but leaves no room for granularity.

Completeness4/5

For the stated purpose (URL-to-image capture, including multi-step goal flows) the single tool covers the core lifecycle with parameters for goals, actions, values, and credit budgets. Minor gaps like explicit viewport/format variants, batch capture, or non-image output can be worked around via the existing parameters.

Available Tools

1 tool
screenshotTake a website screenshotAInspect

Render any public URL to a PNG or JPEG image. Cookie/consent banners and chat widgets are removed by default so the result is clean enough to reason about. Returns the image inline. For a page that is several clicks past the URL, pass goal in plain words and Framejet walks the flow before capturing — you do not need CSS selectors, and you could not write them anyway, because the controls for step 2 do not exist until step 1 has happened. Any text to be typed must be supplied in values; nothing is ever invented. If the goal cannot be reached the call fails and no credits are spent, so a returned image always means the goal was reached. On plans that price goals per block (10 credits a block, a screenshot is 1) max_credits is the most a goal may spend; it stops with goal_budget_exceeded rather than go past it. When you do know the page, actions is cheaper, faster and deterministic.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe http(s) page to capture
goalNoPlain-words description of the page state to reach before capturing, ending with when to stop. Example: 'Search for the Colosseum article, open it, then open its View history page. Stop when the revision list is visible.' Needs `values` for anything that must be typed.
cleanNoStrip cookie banners / chat widgets, default true
delayNoExtra wait in ms after load
widthNoViewport width, default 1280
formatNoImage format, default png
heightNoViewport height, default 800
valuesNoExact strings a `goal` step may type into a field. Framejet picks among these and never invents text; if none fits, the capture fails.
actionsNoDeterministic alternative to `goal` when you already know the page: ';'-separated steps, each verb:arg — click:<css>, type:<css>=<text>, waitfor:<css>, wait:<ms>, scroll:<px>. Prefer this over `goal` whenever you can write the selectors.
full_pageNoCapture the whole scroll height (default false)
max_creditsNoMost credits a `goal` may spend, default 10. The maximum is reserved while the goal runs and the unused part is released. Ignored on plans where a goal costs one credit.

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and meets it well: discloses banner/chat widget removal by default, inline image return, that values must be supplied and nothing is invented, that failure costs no credits, the plan-based pricing, and the goal_budget_exceeded stop behavior. This is rich behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and key behavioral facts, but is long and includes some colloquial digressions ('you could not write them anyway'). Not bloated enough to obscure the core, but not tightly structured either.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers a complex 11-parameter tool adequately: explains the goal/actions/value interplay, cost model, failure semantics, and defaults. No output schema so it correctly notes the inline return. Would be complete with explicit mention of the three unmentioned params (delay, width, height are addressed in schema, but the description doesn't tie them into the overall capture flow).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the schema documents each parameter, but the description adds meaningful semantic context: how `goal` and `values` interact, what `max_credits` does on different billing plans, and the deterministic nature of `actions` vs `goal`. It goes beyond restating schema descriptions without fully explaining every parameter's edge case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Render any public URL to a PNG or JPEG image', reinforced by 'Returns the image inline'. The purpose is clear, but with no sibling tools present there is no differentiation work to do, so a 5 for sibling separation isn't warranted here.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit context for using `goal` (several clicks past the URL), shows the `actions` alternative is 'cheaper, faster and deterministic', and notes default clean behavior. No explicit when-not-to-use or cost comparison beyond credits per block, so it falls short of the top score.

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.

  1. 1 tool update
    • Changedscreenshot1 field changed
      • addedInput schema / properties / max_credits
        Added value: +{
+  "anyOf": [
+    {
+      "const": 10,
+      "type": "number"
+    },
+    {
+      "const": 20,
+      "type": "number"
+    },
+    {
+      "const": 30,
+      "type": "number"
+    }
+  ],
+  "description": "Most credits a `goal` may spend, default 10. The maximum is reserved while the goal runs and the unused part is released. Ignored on plans where a goal costs one credit."
+}
  2. 1 tool update
    • First observedscreenshot

Related MCP Connectors

Related MCP Servers

Try in Browser
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources