Steel MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STEEL_LOCAL | No | true drives a local steel-browser and waives the API key. | false |
| STEEL_API_KEY | No | Required for Steel Cloud. Never sent to a self-hosted deployment. | |
| STEEL_PROFILE | No | browse or scrape. | browse |
| STEEL_BASE_URL | No | Steel REST base URL. A trailing /v1 is fine either way. | https://api.steel.dev |
| STEEL_CONNECT_URL | No | CDP endpoint, derived from the base URL when self-hosted. | wss://connect.steel.dev |
| STEEL_MAX_SESSIONS | No | Live sessions plus pending creates per credential; enforced across replicas when using Redis. | 10 |
| STEEL_SESSION_TIMEOUT_MS | No | Default immutable session lifetime. A create request may choose up to 24 hours, within the account maximum. | 900000 |
| STEEL_INACTIVITY_TIMEOUT_MS | No | Idle release. Long enough for a handoff, so an abandoned browser can live about 10 minutes. | 600000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| steel_scrapeA | Read a web page as markdown or HTML through a real browser, so JavaScript-rendered pages and sites that block plain HTTP fetches still work. Starts no browser session, so there is nothing to release afterwards. Always returns the page links and metadata alongside the content. Use this first for anything you only need to read; reach for steel_session_create only when you need to click, type or move through several pages. |
| steel_screenshotA | Capture a page image. URL captures are user-facing PNG artifacts; session captures are model-visible JPEG evidence. Pixels are not action targets, so use steel_snapshot to click or type. |
| steel_pdfA | Render a page to PDF and return a link to the file. Starts no browser session. Use steel_scrape if you want to read the text — the PDF link is for handing a document to a person. |
| steel_session_createC | Billed; profiles/credentials via session_options; release. |
| steel_session_releaseA | Shut down the current browser and stop the meter. Safe to call twice. Its current URL and session-only page state are gone afterwards. A profile is saved only when persistence was requested. Read what you need first; this reports the final URL and title. |
| steel_navigateA | Navigate a live session and wait for it to settle. Reports the final URL and changes; set include_snapshot to also read the page. |
| steel_snapshotA | Return the page as a compact accessibility tree with a @eN reference on every element you can click or type into. This is the read to use before acting. Elements with no reference cannot be targeted. If you already know what you are looking for, steel_find is much cheaper. |
| steel_findA | Find labelled elements by text, safe regex or role and return their @eN refs. |
| steel_actA | Click, type, fill a form, select an option, hover, scroll, press a key, go back, or dismiss a cookie or consent overlay. Target elements by the @eN reference from steel_snapshot or steel_find, or by a CSS selector. Always reports what actually changed, and says so plainly when nothing did. |
| steel_wait_forB | Wait for text, a CSS selector or URL; all supplied conditions must match. |
| steel_session_diagnosticsA | Read live/released activity or list live handles; never starts a browser. |
| steel_session_handoffA | Pause for a person to take exclusive control of this same live browser, then resume only after hand-back. Use for sensitive input, local files, review, or any manual step. |
| steel_session_replayA | Call only when the user explicitly asks to watch or replay a finished session. Returns its Steel dashboard link without starting a browser; use steel_session_diagnostics to inspect or explain activity. |
| steel_batchA | Run known reversible steps whose later targets need no fresh read. Stops on failure or login/challenge; hand off the same session and resume only unrun steps. Stop before payment/final confirmation. |
| steel_session_optionsC | Find profiles/credentials; plan setup. |
| steel_session_live_viewC | App-only viewer and control lease; no page content. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| session-viewer | Watches and securely takes control of the same live browser, inline in the conversation. |
TDQS
Scored across 16 tools
Most tools have clearly distinct roles, and the descriptions are unusually explicit about which read, act, or session-management tool to use. The only mild confusion is among session_live_view, session_diagnostics, and session_replay, but their definitions separate active viewing, activity inspection, and replay.
All tools share the steel_ prefix and consistent snake_case, and most follow an action-oriented style like scrape, navigate, find, act, and wait_for. A few noun-style names such as session_live_view, session_options, and session_diagnostics deviate slightly from the dominant verb_noun pattern, but the overall scheme remains predictable.
Sixteen tools is slightly above the typical well-scoped range, but the browser-automation domain legitimately needs separate read, act, session-lifecycle, and diagnostic tools. Each tool appears to earn its place rather than duplicating another.
The toolset covers the full browser-automation lifecycle: non-session reads, session creation and release, navigation, element discovery, acting, waiting, diagnostics, human handoff, replay, and batch execution. There are no obvious dead ends; the surface supports both lightweight scraping and complex interactive sessions.