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

scratch-unified-mcp

by blessed0x
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Spy List Packages

spy_list_packages

Check which Python packages are installed in the ScratchPy environment to know what libraries are available for your projects.

Instructions

Python packages installed in the environment ScratchPy uses.

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": "spy_list_packages"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it lists installed packages, implying a read-only operation, but does not explicitly confirm safety, absence of side effects, or any prerequisites. It also does not mention what happens if the environment is unavailable or how the output is structured. The description is minimal and does not add behavioral context beyond the obvious.

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 a single, concise sentence that states the resource and action without redundancy. It is appropriately sized for a tool with no parameters and no complexity. It is front-loaded with the key information, and every word contributes meaning.

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

Completeness3/5

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

Given the tool's simplicity (no parameters, no annotations, and an output schema that likely documents return values), the description is adequate but could be slightly more explicit. It covers the core purpose, but does not mention that it is a read-only operation or any environment assumptions. Since the output schema exists, the lack of return format details is acceptable, but the description could note the read-only nature for clarity.

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 tool has zero parameters, so the schema coverage is trivially 100%. The description adds no parameter details because there are none to add. Per the rubric, with 0 parameters the baseline score is 4, and the description does not need to compensate for any missing parameter information.

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

Purpose4/5

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

The description states a specific verb ('list') and a clear resource: Python packages installed in the environment ScratchPy uses. This clearly distinguishes it from siblings like spy_install_package and spy_add_package_blocks, which involve modifying packages rather than listing them. However, it does not explicitly say 'returns a list' or mention the output format, though the verb 'list' is implied by the name and the phrase 'packages installed'.

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 provided on when to use this tool versus alternatives. The description only states what the tool does, with no mention of contexts where listing packages is appropriate, nor any comparison to sibling tools like spy_install_package or spy_add_package_blocks. An agent must infer usage from the tool name and context.

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