Skip to main content
Glama
Sign In
scratch-unified-mcp

scratch-unified-mcp

by blessed0x
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sb3 Stop Project

sb3_stop_project

Stops the running Scratch project via the TurboWarp Desktop bridge. Halts execution to reset or end testing.

Instructions

Stop in TurboWarp Desktop via bridge. (proxied)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "sb3_stop_project"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only reveals that the operation is 'proxied' through a bridge. It does not mention side effects, whether a project must be running, whether the stop is abrupt or graceful, or any state changes beyond stopping.

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?

The description is very short and contains no filler, which suits a tool with no parameters. The only minor issue is that '(proxied)' may be redundant with 'via bridge', but overall it is efficient.

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

Completeness2/5

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

Even for a parameterless tool, the description omits essential usage context: what state the project must be in, what 'stop' affects in TurboWarp Desktop, and how this differs from the many sibling stop/vm tools. The output schema exists, so return values need no explanation, but the behavior and prerequisites are still underspecified.

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?

The input schema has zero parameters with 100% coverage, so the description has no parameter documentation burden. Baseline 4 is appropriate for a parameterless tool.

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

Purpose3/5

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

The description states a specific action ('Stop') and a context ('in TurboWarp Desktop via bridge'), so it is not a tautology. However, it does not explicitly say what is being stopped; the object 'project' is only implied by the title. It also does not distinguish itself from similar sibling tools like sb3_vm_stop, leaving some ambiguity about scope.

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

Usage Guidelines2/5

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

No guidance is given for when to use this tool versus alternatives such as sb3_vm_stop or other project control tools. The phrase 'via bridge' and '(proxied)' hints at an environment difference, but the description never states conditions, prerequisites, or when not to use it.

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

Deploy Server

Other Tools