SolidPing

Official

Overview Schema Source Related Servers Discussions Admin

Probe a target

probe

Read-onlyIdempotent

Test a JavaScript check before creating it, fetch a URL, or snapshot a page to choose browser selectors. Read-only runs return status, console output, and metrics.

Instructions

Explore a target and test a js check before create_check, without saving anything. kind=script runs a js check script exactly as a SolidPing worker would and returns status, output (with console) and metrics; env carries plaintext parameters and secrets only NAMES the secret parameters, which run empty. kind=fetch GETs a URL from the server. kind=browser snapshots a page to pick selectors for browser steps. Reaches the URL or script target you name. Read-only: works with mcp:read tokens.

Input Schema

TableJSON Schema

Name	Required	Description
`env`	No	Plaintext parameters exposed as env.NAME, e.g. {"BASE_URL": "https://acme.com"}.
`url`	No	Absolute http(s) URL.
`kind`	Yes	What to run. "script": run a js check script once (needs script). "fetch": HTTP GET url and return status, headers and the first 16 KB of the body. "browser": open url in the headless browser and return its accessibility-style tree with a CSS selector per element.
`script`	No	The js check script (a function body that returns {status, ...}).
`secrets`	No	Names of the secret parameters the script reads; they run empty.
`timeout`	No	Run timeout as a duration string (default and max 30s).

Output Schema

TableJSON Schema

Name	Required	Description
`output`	No	The script's output object, with console output under `console`.
`status`	Yes	up, down, timeout or error, as a SolidPing worker would report it.
`metrics`	No	The script's metrics.
`durationMs`	No	Run duration in milliseconds.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.38.5Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/openWorld/destructive, yet the description adds real behavioral context: kind=script runs exactly as a worker would, secrets are supplied by NAME only and run empty, and kind=fetch executes server-side. These caveats materially affect how an agent constructs the call.

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

Conciseness4/5

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

Dense but front-loaded: the purpose and no-save guarantee come first, then the kind-by-kind breakdown. Every sentence carries information relevant to invocation, though the kind explanations are somewhat tightly packed.

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

Completeness5/5

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

For a 6-parameter, enum-bearing, nested-object tool with annotations and an output schema, the description covers the modes, the auth requirement, and the secrets caveat. Return shape is delegated correctly to the output schema, so nothing essential is missing.

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 baseline is 3. The description goes beyond the schema by explaining the semantics of `env` (plaintext parameters) and the security-relevant nuance that `secrets` are given by name and run empty, which is the kind of detail an agent must reason about.

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

Purpose5/5

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

States a specific verb and resource ('explore a target and test a js check') with the crucial scope qualifier 'without saving anything', and positions itself relative to create_check. An agent can distinguish it from create_check/run_check/validate_check without opening a schema.

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?

Explicitly frames the tool as a pre-flight for create_check and states it is read-only with mcp:read tokens, which tells the agent when it is safe/appropriate. It does not explicitly contrast with sibling alternatives like validate_check or run_check, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.