Page History

Reference Cross-tool conventions for the FrameworX MCP SDK , the surfaces it ships, and the tooling extension model— build-visibility propagation from the compile engine into every write-capable MCP tool response.

AI Integration → MCP SDK Reference

Principle: MCP Surfaces, It Does Not Implement

The FrameworX compile engine is unchanged in 10.1.5. No new compiler, no new validation passes, no new error categories. The MCP SDK is a thin adapter over product capability — when the product gains a signal worth exposing, the adapter routes it; when the product lacks a signal, the adapter does not fabricate one. Build visibility follows this principle: the compile output already existed inside Designer and inside the produced .dbsln; the 10.1.5 work was to surface it to MCP callers.

Practically, this means the build block described below is drawn from the same internal sources an engineer already consults — the incremental compile result held by the Designer save pipeline, the error columns on the four *Contents tables in the solution file, and the per-object diagnostics produced by RuntimeBuildAndPublish.

The build Block

All MCP tools that report compile output return the same JSON shape. The shape is stable across DesignerMCP, ConsoleMCP, and the new verify_solution_file tool.

{
  "objects": [
    {
      "type": "Script|Display",
      "name": "<object name>",
      "status": "ok|error",
      "diagnostics": [
        { "line": <int>, "msg": "<string>" }
      ],
      "elapsedMs": <int>
    }
  ],
  "summary": {
    "built":     <int>,
    "failed":    <int>,
    "skipped":   <int>,
    "timestamp": "<ISO8601>"
  }
}
      

Fields

Affected Tables

Four tables carry user-authored .NET and participate in the build pipeline:

A write that touches a row in any other table does not produce a build block (there is nothing to compile). A write that touches a row in one of these four tables carries per-row compile feedback in its response.

Where The Block Appears

Source Of The Data

DesignerMCP draws the build block from the live Designer compile pipeline — the same path that populates the Output pane when an engineer saves a script or runs RuntimeBuildAndPublish.

ConsoleMCP has no live Designer. It reads the same information directly from the produced solution file. A .dbsln is a SQLite database; each of the four affected tables has a companion *Contents table (ScriptsTasksContents, ScriptsClassesContents, ScriptsExpressionsContents, DisplaysListContents) whose error columns hold the compile result written at build time. ConsoleMCP queries those columns and assembles the build block. This is not stdout parsing of SolutionCreator logs — it is a direct read of the compiled result persisted inside the .dbsln.

Agent Usage Pattern

A well-behaved agent writes, reads the compile field on the response, and stops on the first error status rather than piling up additional writes on a broken tree. Typical loop:

1. write_objects([...])                    # Designer or Console
2. inspect response[i].compile.status      # for each affected row
3. if any status == "error":
     fix the offending diagnostics and retry
   else:
     proceed to the next batch
4. at commit boundary (Designer): designer_action('build', rebuild_all=true)
   at commit boundary (Console):  create_solution_file / update_solution_file
5. inspect summary.failed; stop if > 0
      

The commit-boundary step is what catches cross-object breakage (an edit to a Script Class that breaks a Script Task referencing it): the row-level compile on a single write only reports what the incremental pipeline saw for that object; the commit-boundary build reports the whole tree

Server Surfaces

The SDK ships seven servers across three families. Each one is a distinct executable with its own process, transport, and tool surface.

The HTTP servers add bearer-token authentication and DNS rebinding protection defaults suitable for Parallels-internal Mac-to-Windows networks. Use a reverse proxy if you expose the HTTP surface beyond a trusted subnet.

Port Reservations

The HTTP servers use a fixed default port. The full reserved range — including the block reserved for Tatsoft internal MCP tooling — is documented here so that custom integrations and remote setups do not collide with future additions.

To run multiple instances of an HTTP server on the same host (for example, one runtime per execution profile), pass /ListenPort:N on the command line, or set per-instance appSettings.ListenPortN keys with the instance suffix in the JSON config. See Runtime MCP Reference for the multi-runtime pattern.

Runtime Requirements

Verify with dotnet --list-runtimes. A mismatched runtime surfaces as the server failing to start under Claude Desktop or Claude Code.

Exception: RuntimeMCPHttpService targets .NET Framework 4.8 because it uses System.ServiceProcess for Windows Service Control Manager integration. It launches RuntimeMCPHttp.dll (net10.0) as a child process at service start, so the .NET 10 runtime is still required on the host.

Transport Model

Every server speaks JSON-RPC 2.0 over its transport. The SDK framing rules follow the MCP 1.2 streamable-HTTP specification for the HTTP servers and the stdio specification for the stdio servers.

stdio servers

The MCP client spawns the server as a subprocess. stdin carries requests, stdout carries responses, stderr is reserved for logging. Environment variables set on the client process flow to the server.

HTTP servers

The server listens on its configured port. The client negotiates a session over POST /sse and then streams events over GET /sse. Authorization is Authorization: Bearer <token>. The token is configured in %APPDATA%\FrameworX\Mcp\config.json on first run.

Tool Reference

Each tool-level reference lives on its own page.

• ConsoleMCP Reference — file-based workspace tools.
• Runtime MCP Reference — live-runtime tools (shared between RuntimeMCP and RuntimeMCPHttp).
• designer_action Reference — Designer visual and runtime control actions.
• AI Designer Connector — live Designer tools (shared between DesignerMCP and DesignerMCPHttp).

Extensibility

The SDK is NOT a public plug-in surface. Tools are compiled into the shipped executables and are not loaded from user-supplied assemblies. The extension path for customer-specific behavior is via Claude Skills (markdown playbooks loaded by the MCP client) and via search_docs, both of which run on top of the existing tool catalog.

For customer-specific automation via scripts and expressions, see Skill Scripts Expressions.

Version History

FrameworX

Anthropic MCP SDK

Notes

10.1.3

1.0

Initial ship of DesignerMCP and DesignerMCPHttp.

10.1.4

1.1

ConsoleMCP and ConsoleMCPHttp added. RuntimeMCP (stdio) added with the initial runtime tool surface.

10.1.5

1.2

.

In this section...