Skip to main content
All 53 tools are listed here. How many your host actually sees comes down to HOPPSCOTCH_TOOL_PROFILE, which defaults to core and exposes 39 of them. Each table carries a Profiles column telling you where that tool is available, and “All” means every profile, minimal included. CRUD is shorthand for the four basic operations on a resource: create, read, update, and delete.
core and standard are separate branches of full, not a ladder. Switching from core to standard loses execute_request, validate_response, generate_code, generate_documentation, and all eleven request CRUD tools. Choose full if you need both sides.
The profile gates discovery and execution together. A tool outside your profile is invisible to the host and refused even if an agent names it directly.

​
Cloud behavior

Against a self-hosted instance, Community or Enterprise, every tool works. On Cloud, this server refuses one tool, and one other is unavailable because of a backend limitation: Those are the two tools unavailable on Cloud. No other tool carries a Cloud-specific check in this server. Apart from get_user_collection, the personal collection, request, and environment tools are all available there, reads included. execute_request and validate_response read personal environments only, so passing a team environment ID is rejected on either deployment. See Request execution.

​
Teams

Team discovery and administration. list_teams and get_team_info are read-only and ship in core. Every other tool here is team administration and requires standard or full.
Both read-only tools return each member’s user ID, display name, and email address along with their role. list_teams does this for every team you belong to, and it is in the default profile, so asking an agent to list your teams sends your colleagues’ email addresses into the model’s context.
remove_team_member and update_team_member_role identify a member by user ID, while invite_team_member uses an email address. Read the user ID from get_team_info first. Removing or demoting a team’s only owner is refused before the call is sent, though that check is a convenience: the backend is authoritative, and if membership cannot be read the call proceeds and the backend rejects it.

​
Team collections

Collections inside a team workspace. These work on both Cloud and self-hosted, except search_team_requests.

​
Team environments

Environment variables scoped to a team workspace. These work on both Cloud and self-hosted.
Reading an environment masks every secret value as <secret hidden>, and an update replaces the entire variable list. Listing an environment and submitting it back would therefore write the mask over the real secret, so the server refuses that write. To leave a secret alone, omit the variables field entirely, which keeps every variable as it is. If you send variables at all, it replaces the whole list, so include every variable you mean to keep and give the secret its real value.

​
Personal collections

Collections in your personal workspace. get_user_collection is the only one refused on Cloud. See Cloud behavior.

​
Personal environments

Environment variables scoped to your personal workspace. These work on Cloud and self-hosted alike.

​
Team requests

Individual requests stored inside a team collection.
The read tools here return each request’s full stored JSON, including any headers, body, and authentication saved with it. Unlike environment listings, request reads are not redacted, so a credential stored in a saved request reaches the model exactly as stored.

​
Personal requests

Individual requests stored inside a personal collection. These work on Cloud and self-hosted alike.

​
Request execution

The tools that send real HTTP traffic. Both refuse targets on your own machine or a private network, and both cap the response body, as described in Overview. The 30 second timeout is a default that a call can override with its own timeout argument, between 1,000 and 120,000 milliseconds.
validate_response does not validate against a JSON Schema. The jsonSchema field is a deprecated alias of jsonObject, and both perform the same check: whether the body parses as a JSON object or array. Passing a schema document does not compare the response to it, and no error tells you the schema was ignored. Use jsonObject: true for the check that actually happens.

​
Code generation

Turn a request definition into code or documentation.
Credential masking is best-effort, not a guarantee. It covers the structured auth object, credential-looking header names and query parameters, and JSON or form-encoded body fields. An XML, plain-text, multipart, or binary body is left untouched, and a credential in an unrecognized field is not masked. Read the output before sharing it, even with masking enabled.

​
Session

Sign-in control.

​
Variable substitution

execute_request and validate_response substitute {{variable}} references from your personal environments. The behavior has several edges.
  • Substitution applies to the URL, header values, and the body. It does not apply to the auth block or to header names.
  • The auth block handles bearer, basic, and API key authentication. For anything else, set the Authorization header yourself as a normal header.
  • Only personal environments are read. Passing a team environment ID is rejected.
  • These tools do not inherit authentication from a parent collection. They use only the auth you pass in the call.
  • When you select an environment, an unresolved {{placeholder}} in the URL, the body, or a header value fails the call. When you select no environment, an unresolved {{placeholder}} is sent rather than failing the call, because there is nothing to resolve it against. In a URL path the braces are percent-encoded on the wire.
  • The unresolved-placeholder check covers the same three places substitution does, so two locations are outside it entirely. A placeholder in a header name is never substituted or checked, and the call then fails before anything is sent, because braces are not legal in a header name. A placeholder in the auth block is also never substituted or checked, and what reaches the wire depends on the authentication type. A bearer token is sent as written, Basic credentials are base64-encoded, an API key added to the query is percent-encoded into the URL, and an API key whose name is a placeholder fails the same way a placeholder header name does, but only in the default header placement. Added to the query instead, the name is percent-encoded and goes out as written.
  • Values marked secret substitute into a request to any origin by default. Set HOPPSCOTCH_SECRET_ALLOWED_ORIGINS to restrict which origins may receive them.

​
What scrubbing covers

Secrets that a request substituted are scrubbed from the response body, headers, and error text before the model sees them. The scrubber works by matching the forms a secret takes when it is sent: the raw value, its JSON-escaped form, and the percent-encoded forms a URL produces for it. It does not match base64 or any other re-encoding. Matching on forms is what makes this best-effort. Either end of the request can produce something the forms miss:
  • Your request can drop part of the value. Everything after a # becomes a URL fragment and never leaves your machine, so the target only ever receives the part before it. When it echoes that prefix back, nothing matches.
  • The target can change what it received before echoing it, by decoding a percent-escape, turning a + back into a space, or splitting the value at a delimiter. Again, nothing matches.
Narrower still is what gets tracked at all. Only values flagged secret go into the scrub set, so a plain variable, a credential in the auth block, and anything typed straight into a header are never candidates. And the set is per-request: it holds the secrets that particular call substituted, not everything sitting in the environment.
Do not rely on response scrubbing for confidentiality. It is a safety net for values the server itself substituted, not a guarantee that no credential reaches the model. HOPPSCOTCH_SECRET_ALLOWED_ORIGINS does not close the gap either: it gates which origins may receive values flagged secret, and has no bearing on plain variables, auth block credentials, or hand-written headers.

​
Annotations

Every tool carries four MCP annotation hints: readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. Hosts may use them to decide whether to ask you before running a tool.
These are hints for your host, not a server-side guard. The server has no confirmation step. A delete_ tool or a team-membership change takes effect on the first call. Whether you get a prompt is your host’s decision.
execute_request and validate_response are marked both destructive and open-world, because the target host is arbitrary and may perform any write the credentials in the request allow. The hints come from each tool’s name prefix, with a few hand-written exceptions, which makes them coarser than they look. Twenty-five tools are marked destructiveHint: true, seventeen of them in core. The twelve that write without being marked destructive are every create_, import_, and duplicate_ tool, plus invite_team_member. That last one is the sharp edge. An invitation is additive in shape, so it advertises destructiveHint: false, yet it accepts a role of OWNER. A host that prompts only on the destructive hint will not ask before an ownership grant. invite_team_member is not in the default profile, so reaching it takes standard or full.

​
Next steps

Overview

Installation, host setup, authentication, and configuration.

Troubleshooting

Errors you may see, what causes them, and how to fix them.