Skip to main content
Glama

ppsspp_breakpoint_list

List all CPU execution breakpoints to inventory or verify current breakpoints before modifying them.

Instructions

PURPOSE: List all currently-set CPU execution breakpoints. USAGE: Inventory before bulk-removing, or sanity-check what's set. BEHAVIOR: No side effects — pure read. RETURNS: Multi-line text, one line per breakpoint with its address and any conditions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Handler for ppsspp_breakpoint_list tool: calls PPSSPP's cpu.breakpoint.list via WebSocket, formats the response as multi-line text listing each breakpoint's address, enabled status, and condition.
    case "ppsspp_breakpoint_list": {
      const r = await pp.call<{ breakpoints?: Array<{ address: number; enabled?: boolean; condition?: string }> }>("cpu.breakpoint.list");
      const bps = r.breakpoints ?? [];
      if (bps.length === 0) return ok("No breakpoints set.");
      const lines = bps.map((b) => `  ${addrHex(b.address)} ${b.enabled === false ? "(disabled)" : ""}${b.condition ? ` if ${b.condition}` : ""}`);
      return ok(`${bps.length} breakpoint${bps.length === 1 ? "" : "s"}:\n${lines.join("\n")}`);
    }
  • Schema/type definition for ppsspp_breakpoint_list tool: no input parameters required, returns multi-line text.
    {
      name: "ppsspp_breakpoint_list",
      description:
        "PURPOSE: List all currently-set CPU execution breakpoints. " +
        "USAGE: Inventory before bulk-removing, or sanity-check what's set. " +
        "BEHAVIOR: No side effects — pure read. " +
        "RETURNS: Multi-line text, one line per breakpoint with its address and any conditions.",
      inputSchema: { type: "object", properties: {} },
    },
  • src/tools.ts:383-391 (registration)
    Registration entry in the TOOLS array: defines the tool name, description, and input schema for the MCP ListTools handler.
    {
      name: "ppsspp_breakpoint_list",
      description:
        "PURPOSE: List all currently-set CPU execution breakpoints. " +
        "USAGE: Inventory before bulk-removing, or sanity-check what's set. " +
        "BEHAVIOR: No side effects — pure read. " +
        "RETURNS: Multi-line text, one line per breakpoint with its address and any conditions.",
      inputSchema: { type: "object", properties: {} },
    },
  • Helper function addrHex used in breakpoint_list handler to format addresses as 8-digit zero-padded hex strings.
    function addrHex(n: number): string {
      return `0x${n.toString(16).toUpperCase().padStart(8, "0")}`;
Behavior4/5

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

Description states 'No side effects — pure read' and identifies no side effects. Without annotations, this directly addresses behavioral transparency for a simple read operation.

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

Conciseness5/5

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

Description is three clear lines with labels (PURPOSE, USAGE, BEHAVIOR, RETURNS). No wasted words; front-loads key info.

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?

Given no output schema, description explains return format ('Multi-line text, one line per breakpoint with its address and any conditions'). Complete for a simple list tool.

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?

Input schema has 0 parameters, and schema description coverage is 100%. Baseline for 0 parameters is 4; description adds no param info (not needed).

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?

Description states 'List all currently-set CPU execution breakpoints' with a specific verb (list) and resource (breakpoints). Clearly distinguishes from siblings like ppsspp_breakpoint_add and ppsspp_breakpoint_remove.

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 says 'USAGE: Inventory before bulk-removing, or sanity-check what's set.' Provides clear context but no negative guidance or alternatives, though not strictly needed.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dmang-dev/mcp-ppsspp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server