Path of Building MCP Server

Overview Schema Source Related Servers Discussions Admin

export_build

Export a copy of a Path of Building build to an XML file, creating a variant from an existing build file for backup or sharing.

Instructions

Export a copy of a build to an XML file. Creates a variant/copy from an existing build file. NOTE: This does NOT export from Lua bridge - use save_tree to apply Lua bridge modifications back to files.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "build_name": "<build_name>",
      "output_name": "<output_name>"
    },
    "name": "export_build"
  }
}

Input Schema

Name	Required	Description
`notes`	No	Additional notes to append to build notes
`overwrite`	No	Allow overwriting existing file (default: false)
`build_name`	Yes	Source build filename (e.g., 'MyBuild.xml')
`output_name`	Yes	Output filename (without .xml extension)
`output_directory`	No	Sub-directory under POB_DIRECTORY to export into (optional, defaults to POB_DIRECTORY/.pob-mcp/exports). Paths outside POB_DIRECTORY are rejected.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Nov 13, 2026

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are supplied, so the description must carry the behavioral burden: it does disclose that the operation creates a copy rather than mutating the source and warns about the Lua bridge path. It stops short of describing what is returned (e.g., resulting file path), whether an existing output is silently replaced, or any side effects on the source build, which matters for a file-writing tool.

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?

Three short sentences, front-loaded with the purpose and followed by the disambiguation note, with no filler. The first two sentences partially restate each other ('export a copy' / 'creates a variant/copy'), which is minor redundancy but slightly dilutes the front-loading.

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?

For a file-writing tool with no annotations and no output schema, the definition covers purpose and one important exclusion but omits return behavior, collision handling beyond the schema's flag, and any statement about source-build integrity. The rich schema reduces the gap on parameters, but the behavior of the write itself remains thin.

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 description coverage is 100%, so all five parameters including overwrite defaults and POB_DIRECTORY path restrictions are already documented in the schema. The description adds only the conceptual framing of 'variant/copy' and does not explain parameter interactions, so the baseline of 3 applies.

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?

States a specific verb and resource ('Export a copy of a build to an XML file') and clarifies the semantics of the output as a variant/copy of an existing build. It also contrasts itself against a named sibling (save_tree) for the Lua bridge case, so the agent can separate the two without opening either schema.

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?

Provides an explicit exclusion: this does not export Lua bridge changes, and directs the agent to save_tree for that workflow. However, it gives no guidance on choosing between this and other nearby siblings such as export_build_summary or snapshot_build, so usage is clear only for the one case called out.

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