SolidPing

Official

Overview Schema Source Related Servers Discussions Admin

Probe a target

probe

Read-onlyIdempotent

Test a JS check script, fetch a URL, or snapshot a page in a headless browser to pick selectors before create_check — read-only, saving nothing.

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. kind selects the mode; the other params apply only to their kind (script: script/env/secrets/timeout; fetch and browser: url). Reaches the URL or script target you name. Read-only: works with mcp:read tokens.

Input 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

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.

Changed5 schema fields changedv0.42.0Oct 27, 2026
- addedInput schema / properties / kind / maxLength
```
Added value: +2048
```
- addedInput schema / properties / kind / minLength
```
Added value: +1
```
- addedInput schema / properties / script / maxLength
```
Added value: +65536
```
- addedInput schema / properties / timeout / maxLength
```
Added value: +2048
```
- addedInput schema / properties / url / maxLength
```
Added value: +2048
```
Changed2 schema fields changedv0.41.0Oct 23, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedOutput schema / additionalProperties
```
Added value: +false
```
Addedv0.38.5Oct 15, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds real behavioral detail beyond the annotations: nothing is persisted, secrets resolve to empty values (a non-obvious and important caveat), env is plaintext, and the timeout default/max is 30s. It also names the auth scope (mcp:read tokens). The return-value recount partially duplicates the existing output schema.

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?

Front-loaded with purpose and the create_check relationship, then organized mode-by-mode. Sentences are dense but each clause carries information; only the 'Reaches the URL or script target you name' line is close to filler.

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 six-parameter, three-mode tool with an output schema, this covers everything an agent needs: mode semantics, per-mode parameter applicability, secret handling, timeout bounds, and auth scope. Errors and non-http URL handling are the only untraced corners.

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 bar is the baseline of 3, and the description exceeds it by explaining the cross-parameter rule: the other params apply only to their kind (script/env/secrets/timeout for script; url for fetch and browser). That conditional mapping is not expressible in the flat schema.

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 (probe/explore) and resource (target), then enumerates the three distinct modes (script/fetch/browser) with what each returns. It explicitly positions itself against create_check, so an agent can distinguish it from the sibling 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?

Gives a clear when-to-use: testing a js check before create_check, with an explicit 'without saving anything' exclusion. It does not, however, contrast with the closely related run_check or validate_check siblings, which an agent must resolve on its own.

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