Skip to main content
Glama
AerialByte

mcp-netcoredbg

by AerialByte

attach

:

Instructions

Attach debugger to a running .NET process

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
processIdYesProcess ID to attach to
sessionIdNoSession ID for this debug session (auto-generated if not specified)

Implementation Reference

  • The DebugSession.attach() method that implements the core attach logic. Creates a DAP client, initializes it, and attaches to the specified process ID. Saves session config with mode: 'attach'.
    async attach(processId: number): Promise<void> {
      // Clear any existing state
      await this.cleanup();
    
      this.dapClient = new DAPClient();
      this.setupEventHandlers();
    
      await this.dapClient.start();
      await this.dapClient.attach(processId);
    
      // Save session config
      this.config = {
        program: `process:${processId}`,
        resolvedEnv: {},
        processId,
        startTime: new Date(),
        mode: "attach",
      };
    }
  • Registration of the 'attach' tool with the MCP server using server.tool(). Includes tool name, description, Zod schema for parameters, and the async handler that creates a session and calls session.attach().
    // Tool: attach
    server.tool(
      "attach",
      "Attach debugger to a running .NET process",
      {
        processId: z.number().describe("Process ID to attach to"),
        sessionId: z
          .string()
          .optional()
          .describe("Session ID for this debug session (auto-generated if not specified)"),
      },
      async ({ processId, sessionId }) => {
        // Derive session ID if not specified
        const derivedSessionId = sessionId || `process-${processId}`;
    
        const session = sessionManager.createSession(derivedSessionId);
    
        try {
          await session.attach(processId);
          return textResponse(`${sessionPrefix(session.id)}Attached to process ${processId}\nSession ID: ${session.id}`);
        } catch (err) {
          await sessionManager.removeSession(session.id);
          throw err;
        }
      }
    );
  • Zod schema defining the input parameters for the 'attach' tool: processId (required number) and sessionId (optional string).
    {
      processId: z.number().describe("Process ID to attach to"),
      sessionId: z
        .string()
        .optional()
        .describe("Session ID for this debug session (auto-generated if not specified)"),
    },
  • Low-level DAPClient.attach() helper method that sends the DAP 'attach' request with the process ID to the netcoredbg debugger, followed by configurationDone.
    async attach(processId: number): Promise<void> {
      await this.sendRequest("attach", {
        processId,
      });
    
      await this.sendRequest("configurationDone", {});
    }
Behavior2/5

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

No annotations provided, so description carries full burden. 'Attach debugger' describes the action but omits critical behavioral context: whether the process pauses/breaks on attach, timeout behavior, permissions required, or failure modes for protected processes.

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?

Single sentence, 7 words. Verb-fronted structure. Every word earns its place—zero redundancy while conveying specific domain (.NET) and action.

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?

Simple 2-parameter tool with complete schema documentation. However, lacking annotations, output schema, and behavioral details (attach side effects), description is minimally adequate but leaves gaps for safe operation of process manipulation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, establishing baseline 3. Description adds '.NET' domain context not present in schema, but provides no additional syntax guidance, validation rules, or parameter relationship details beyond 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?

Specific verb ('Attach') + specific resource ('debugger', 'running .NET process'). Clearly distinguishes from sibling 'launch' (which creates new processes) by specifying 'running' and '.NET process'.

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

Usage Guidelines3/5

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

Implies usage through 'running process' (vs launch), but provides no explicit when-to-use guidance or comparison to 'launch' sibling. Agent must infer when to prefer attach over launch.

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/AerialByte/mcp-netcoredbg'

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