Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Xbox Port MCP Inspect my Sims Bustin' Out ISO and start a Spanish port workspace."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English · Configuración · Contribuir
MCP independiente para inspeccionar juegos de Xbox original y coordinar ports para Windows mediante perfiles específicos. Automatiza pasos repetibles del trabajo realizado con Los Sims toman la calle. No convierte cualquier ISO en un juego nativo: necesita un proyecto de recompilación y correcciones para cada título y revisión.
Un perfil incluido: sims-bustin-out-usa. Usa bustinout-recomp y XboxXBERecomp, fijados por commit.
El flujo manual original produjo un juego que su usuario confirmó jugable dentro de una casa, con guardado, textos originales en español e instalador funcional. Esta MCP es una implementación nueva de ese flujo: tiene pruebas de protocolo, lectores, rutas, trabajos y empaquetado. Todavía no se ha repetido una compilación completa del juego de principio a fin mediante esta MCP. La confirmación histórica se distingue de las pruebas de esta versión.
El perfil selecciona los recursos españoles presentes en el juego. La traducción del panel adicional de ajustes de PC no está incluida en esta receta. El instalador está en español. Los Sims conservan su idioma ficticio.
Related MCP server: dspre
Inspección ISO XDVDFS y XBE, identidad y huellas; extracción sin ejecutar el juego.
Rechazo de revisiones desconocidas antes de aplicar correcciones de direcciones.
Fuentes fijadas, correcciones de almacenamiento/idioma y configuración/compilación.
Imágenes del instalador generadas desde vídeos de la copia local, instalador e ISO para Windows.
Verificación del instalador dentro de la ISO y registro separado de observaciones humanas.
No incluye juegos, BIOS, claves, recursos comerciales, capturas, partidas ni ejecutables de juegos recompilados. Cada usuario aporta sus archivos localmente. REA puede ayudar a investigar perfiles nuevos; no es una dependencia obligatoria ni sustituye la implementación de un port.
Python 3.11 o posterior. Desde una copia del repositorio:
python -m venv .venv
.venv\Scripts\python -m pip install .En Linux/macOS usa .venv/bin/python. En esos sistemas solo se ofrece inspección/extracción; la receta de compilación y empaquetado actual está orientada a Windows x64.
Añade el servidor stdio a tu cliente MCP siguiendo examples/mcp.json. Sustituye las rutas por rutas absolutas reales. El comando es el Python de esa instalación y los argumentos son -m xbox_port_mcp.
Inspeccionar/extraer no requiere compiladores. Construir requiere Git, CMake, Ninja, LLVM compatible y entorno MSVC x64; empaquetar añade FFmpeg, Inno Setup, redistribuibles x64 y Windows PowerShell/IMAPI. La MCP no instala estas herramientas. Véase configuración.
Llama a doctor, list_profiles e inspect_iso y verifica la identidad exacta.
Usa create_workspace con profile_id="sims-bustin-out-usa" y language="es".
Llama a start_step en orden: extract (con input_path), prepare, configure, compile. Preparar/configurar ya aplican fixes, también disponible por separado.
Consulta get_job hasta terminar cada trabajo. Detén pasos dependientes ante fallos; cancel_job cancela trabajos propios.
Prueba manualmente el ejecutable: menú, casa y guardar/cargar. record_manual_observation registra solo resultados comunicados por el usuario.
Continúa con artwork, installer, iso, verify_iso, y prueba instalar y abrir el resultado.
Son nueve herramientas, el recurso xbox-port://profiles y el prompt port_workflow. Ejecutar programas está desactivado por defecto. Un trabajo succeeded confirma ese paso, no la jugabilidad.
python -m pip install ".[dev]"
python -m pytest -q
python -m pip wheel . --no-deps --wheel-dir distLas pruebas usan archivos sintéticos. La configuración CI incluye Windows y Ubuntu; eso no equivale a comprobar un juego completo. Código propio bajo MIT; véase atribuciones.
Request cancellation of a job owned by this server session, never an arbitrary PID.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description does not need to restate safety basics. It adds that cancellation is scoped to session-owned jobs and framed as a request, but it does not clarify whether cancellation is immediate or graceful, whether it is idempotent, or what happens if the job has already completed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tightly written sentence with no redundant material. The scope limitation is front-loaded and easy to act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description does not need to explain return values. For a one-parameter cancellation tool, the key missing context is behavioral: what 'request cancellation' means operationally and how the agent should obtain a valid job_id. The scope constraint is helpful, but the description is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, job_id, and schema description coverage is 0%. The description helps by implying that job_id refers to a session-owned job rather than an arbitrary PID, but it does not specify the identifier format or whether job_id comes from get_job or another listing tool. It adds some useful meaning but does not fully compensate for the lack of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Request cancellation') and resource ('a job'), and adds a meaningful scope constraint ('owned by this server session, never an arbitrary PID'). It is clearly distinguishable from read-oriented siblings like get_job or list_profiles. The only slight weakness is that 'request cancellation' leaves the exact effect somewhat open-ended.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'never an arbitrary PID' gives a useful exclusion: do not use this for arbitrary process termination. However, it does not explicitly say when to prefer this over alternatives such as get_job, nor does it describe preconditions beyond session ownership. Usage is implied rather than fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new isolated workspace; no source checkout, extraction or execution occurs.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | es | |
| profile_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that no checkout, extraction or execution happens, but says nothing about what is provisioned, whether the call is idempotent, or what state is created.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the core action front-loaded and the scope caveat immediately after. No filler, though it could have spent a few more words on the required parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and complexity is low (2 params, 1 required). However, the required profile_id and its meaning are entirely unexplained, which is a real gap for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema gives only titles and an enum. The description does not mention profile_id at all, despite it being required, nor explain the language default of 'es'. It fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Create a new isolated workspace') and adds a scope qualifier ('no source checkout, extraction or execution occurs') that separates it from heavier siblings such as start_step or inspect_iso. It does not explicitly name an alternative, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The negative scoping clause implies when to reach for this tool (provisioning without touching source), but there is no explicit when-to-use, when-not-to-use, or named alternative among the siblings. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report local tool availability and execution/network opt-ins. Does not install anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description reinforces this with "Does not install anything," which usefully rules out a side effect an agent might otherwise fear from a tool named doctor, but adds little else about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the positive capability front-loaded and the negative constraint immediately after it. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an output schema, and full annotations, the description only needs to establish scope and absence of side effects, which it does. It stops short of saying what the reported opt-ins mean or when a failure should block subsequent calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The empty schema is consistent with a no-argument probe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Report") and a specific resource (local tool availability and execution/network opt-ins), so the agent knows exactly what comes back. It does not differentiate against any sibling, though the listed siblings are unrelated operations, so the risk of confusion is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name and the phrase "Report local tool availability" imply a diagnostic/preflight use, and "Does not install anything" implicitly excludes remediation. There is no explicit when-to-use statement, no mention of running it before other tools, and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get process result and at most 16 KiB of log tail. A succeeded step is not playability evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, and closed-world behavior, so the description is not responsible for the safety profile. It adds useful behavioral context by disclosing the 16 KiB log-tail cap and warning that a succeeded step is not playability evidence, which affects how the result should be interpreted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core retrieval behavior front-loaded. The second sentence adds a concrete interpretive caveat, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because an output schema exists and annotations cover safety, the definition is not required to explain return values or side effects. However, it omits meaningful context about the sole required input and provides little routing guidance among sibling job tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for the undocumented job_id parameter. It does not mention job_id at all, give its format, or explain where to obtain it; only the property name itself makes the parameter minimally understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: get the process result plus a bounded log tail. It is clearly a retrieval tool rather than a mutation tool, though it does not explicitly name sibling alternatives such as cancel_job or start_step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance, no exclusions, and no alternatives to choose from. The retrieval framing implies it should be used to inspect a job, but the agent must infer that from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an allowed local XDVDFS ISO; return bounded entries and XBE identity, without extracting.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, and the description still adds useful information: the subject must be an 'allowed local' path, entries are returned in bounded form (i.e. limit/offset pagination), and nothing is extracted to disk. It does not spell out what the authorization check looks like or what happens when a path is rejected, but the description does give real value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence. It leads with the verb and the resource, then sets the scope constraint, and it closes with the non-behavioral guarantee of 'without extracting'. It wastes no words and reads naturally as a summary line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema handles return values, and the annotations cover safety, so the remaining burden is small. That said, for a tool whose main failure mode is a rejected path, the description never explains what makes a path 'allowed' or whether the path must be absolute, so it leaves an important operational detail unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the schema alone does not document any of the three parameters; the description supplies some compensation by noting that 'bounded entries' motivate the limit parameter and that 'allowed local' constrains the path. However, it does not describe the offset parameter or explain the limit defaults and bounds, so the agent must make inferences about pagination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (read/inspect) on a specific resource (XDVDFS ISO), and it names the scope (local, allowed) and the output shape (bounded entries plus XBE identity, no extraction). It implicitly distinguishes this tool from the sibling inspect_xbe tool by targeting ISOs rather than standalone XBE files, but it never states that distinction explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without extracting' implies when not to use this tool (for extraction), and 'allowed local' hints at a path-allowlist prerequisite. That said, the description says nothing explicit about when to choose it over inspect_xbe, or about what 'allowed' means operationally, so the agent must infer those things.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect an allowed original Xbox XBE and match its exact identity to a profile.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds domain context that only 'allowed' original Xbox XBE files are inspected and that identity matching against a profile occurs, but it does not explain permissions, failure behavior, or what 'allowed' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant or wasted wording. It delivers the core action and goal efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and read-only, annotations cover safety, and an output schema exists for return values. However, the description leaves gaps around the 'path' parameter and when the tool should be selected over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, 'path', with 0% description coverage, and the description does not explain it. It is only implicitly clear that the path points to an XBE file, with no format, validation, or source details provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and resource ('original Xbox XBE'), and adds the goal of matching exact identity to a profile. It implicitly distinguishes itself from the sibling 'inspect_iso' by operating on XBE rather than ISO files. The term 'allowed' is somewhat vague, but the overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as 'inspect_iso' or 'list_profiles'. The purpose implies a use case, but no conditions, prerequisites, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported game profiles and precisely labelled historical evidence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that – no mention of size, filtering, pagination, or what 'labelled historical evidence' refers to operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It's a single short sentence, which is appropriately sized, but half of it ('precisely labelled historical evidence') carries no clear meaning and reads as filler rather than front-loaded substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, and the annotations cover the safety profile. However, for a list/grounding tool whose value depends on an agent understanding what 'profiles' and 'evidence' mean in this domain, the description leaves a meaningful conceptual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema coverage is 100%, so there is nothing for the description to compensate for. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb is 'List' and the resource is 'game profiles', which is reasonably clear, but the trailing clause 'precisely labelled historical evidence' is opaque – it's unclear whether this returns evidence records, evidence metadata, or something else. The sibling tools (get_job, inspect_iso, etc.) don't overlap conceptually, so no differentiation is strictly needed, but the tool's actual output purpose remains ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this tool, what prerequisites exist, or what alternatives might apply. It's a discovery-style list tool so an agent can infer 'call this to enumerate profiles', but nothing is stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a client-reported human observation separately from automated job evidence. Only call when the user has supplied that observation. This does not independently verify it.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| check | Yes | ||
| outcome | Yes | ||
| workspace_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations establish that this is a non-read-only, non-destructive, closed-world mutation. The description adds meaningful behavioral context beyond that: the observation is client-reported, stored separately from automated evidence, and is not independently verified by the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and front-loads the core action. Every sentence adds useful information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Annotations cover the safety profile and an output schema exists, so return values need less explanation. However, the description leaves critical invocation details undocumented, especially the meaning of check enum values and how to populate outcome, note, and workspace_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are required and schema description coverage is 0%, but the description does not explain workspace_id, check, outcome, or note. It does not clarify what the check enum values mean or how a user-supplied observation should be mapped into outcome and note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it records a client-reported human observation. It also distinguishes the tool from automated job evidence, which separates it from sibling job-related tools such as get_job and start_step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear gating condition: only call when the user has supplied the observation. It also implies that automated or unverified evidence should not be recorded through this tool, though it does not name a specific alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a fixed profile step, never arbitrary shell text. extract needs an allowed ISO input_path. Other steps: prepare, fixes, configure, compile, artwork, installer, iso, verify_iso. Prepare downloads pinned trusted sources; builds may download dependencies when enabled. External steps require XBOX_PORT_ALLOW_EXECUTION=1. Returns a job id, not a completion claim.
| Name | Required | Description | Default |
|---|---|---|---|
| step | Yes | ||
| input_path | No | ||
| workspace_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructive/openWorld), the description adds that prepare downloads pinned trusted sources and builds may fetch dependencies, that external steps are gated behind XBOX_PORT_ALLOW_EXECUTION=1, and that the result is an async job id rather than a completion. Those are concrete operational facts an agent could not infer from the annotations. It doesn't disclose what each destructive step overwrites or whether a failed step leaves partial state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded: the core action and its main constraint come first, followed by per-step and execution-gate details. Every sentence carries operational information, though the flat re-listing of the step enum largely duplicates the schema and only 'prepare' receives elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async, destructive pipeline tool the description covers gating and return semantics well (and an output schema exists, so return shape needn't be restated). However it never explains workspace_id, whether steps must run in a given order, or whether a workspace must be created first via create_workspace — gaps that affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry parameter meaning. It explains the step enum values and adds a conditional constraint on input_path (an allowed ISO path, required for extract), which is useful. workspace_id, the other required parameter, is never mentioned — no scope, format, or prerequisite — so compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a precise verb+resource ('Start a fixed profile step') and an explicit negative constraint ('never arbitrary shell text') that rules out a shell-execution interpretation. It then enumerates the exact valid step values, so an agent knows this is a bounded pipeline initiator. It stops short of 5 only because 'fixed profile step' and what each step actually performs remain partly opaque.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives real when-to-use conditions: 'extract needs an allowed ISO input_path', external steps require XBOX_PORT_ALLOW_EXECUTION=1, and prepare/builds may fetch sources. These are prerequisites that select correct invocation paths. It does not name sibling alternatives (e.g. get_job for polling) explicitly, leaving that inference to 'Returns a job id, not a completion claim'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cancel_jobcreate_workspacedoctorget_jobinspect_isoinspect_xbelist_profilesrecord_manual_observationstart_stepScored across 9 tools
Each tool targets a distinct resource and action: profile listing, job lifecycle (start/get/cancel), evidence recording, environment diagnostics, ISO/XBE inspection, and workspace creation. There is no meaningful overlap between inspection, execution, and observation tools.
Eight of nine tools follow a clear snake_case verb_noun pattern (list_profiles, get_job, cancel_job, inspect_iso, create_workspace, start_step, etc.). The lone exception is 'doctor', which breaks the pattern but is a conventional and readable diagnostic name.
Nine tools is well-scoped for an Xbox porting workflow that must separate job execution, evidence collection, inspection, and environment checks. Each tool has a clear role and none appear redundant.
Core lifecycle coverage exists: profiles can be listed, jobs started/retrieved/cancelled, workspaces created, and artifacts inspected. Minor gaps include no workspace listing/deletion and no explicit job listing, but agents can likely work around these.
Manage SysML2 projects; check, evaluate, verify, query, document and diagram models.
Read, analyze, and safely edit Microsoft Project MPP files.
Read project context and manage tasks in MCPBinder, with access you control.
Durable, shareable and governed project memory with smart triage and explicit project composition.