A running list of what UpDoc's MCP server could do next, and what it deliberately should not. Not a commitment. Comment as things get built, dropped or reconsidered.
Context: #130 built the server, #132 shipped create-from-source. Two tools work today. #129 is the umbrella.
Worth building
Markdown and web sources for create-from-source
The endpoint refuses both, returning "use the backoffice". The extraction services exist, the workflows exist, and groupTourWebPage is configured and Ready.
Cheapest item here. Same code path with a different extractor, and it removes the obvious "why only PDF?" from the tool's description.
preview-extraction — #131
Already open. Runs extraction and returns what would land in each field, creating nothing.
The Content tab does exactly this in the browser, so the pipeline is there. Worth restating why it matters: it lets a session check a PDF before committing, and diagnose a bad mapping without creating and binning a page.
import-report — #133
Also open. Which mappings resolved and which did not.
create-from-source already returns mappedValueCount, but a count without its denominator is not much use — "19" only means something next to "of 19". Turns "did that work?" from a judgement into a fact.
Probably worth building
validate-workflow
Reports a workflow's problems in detail before anything relies on it.
list-workflows already surfaces validation warnings, so this is mostly depth rather than new capability. Useful when a session is choosing between workflows, or when an import produced less than expected and the question is whether the workflow or the PDF is at fault.
find-media
Search the media library for a file, returning size alongside the key.
The specific job is "is this PDF already here, and is it the same revision?". That matters: nine brochures were bulk-seeded ahead of their tours, and one was a stale revision 43 bytes off the live file. A search hit is not proof the right file is there.
Open question whether this belongs in UpDoc's server at all. It is a media-library concern, not an UpDoc one, and Umbraco's server may be the right home.
Not tools, and more valuable than most of them
Publish the server to npm
Nothing above matters much while the server only exists on one machine.
Installing UpDoc's NuGet package does not, and should not, bring a Node process with it — different runtimes, different lifecycles. Consumers would add it via npx in their MCP config, needing the NuGet package installed and an API user configured.
No issue for this yet. Arguably the highest-value item on the page.
Point the backoffice at the endpoint
The create logic now exists twice: C# behind the endpoint, TypeScript in the browser. They agree today. They will not agree forever.
Deliberately deferred — the browser path is what real client work runs on, and it gets switched only after the two are compared side by side on the same PDF.
Release a version containing the endpoint
Tailored Travel's own site runs the NuGet package, so the tool cannot reach it until a release goes out. The mirror works because it references the project directly.
Tagging is Dean's decision alone, as always.
Deliberately not building
create-workflow
Authoring a workflow is a design task, not an import task. The JSON is deliberately AI-readable — a session can already write the files directly, which is the point of storing them as JSON rather than in a database. A tool would add ceremony without adding capability.
publish-document, update-document-properties, and anything else Umbraco already has
Reached by chaining to @umbraco-cms/mcp-dev, which is already configured. Reimplementing them here would be the mistake #132 avoided: tools doing work rather than triggering it.
Anything that judges extraction quality
Whether a price caveat landed in the right slot is a function of one project's PDFs and one project's blueprint. UpDoc users fix that by adjusting their own rules and mappings. Not UpDoc's business, and not something a tool can generalise.
The umbrella issue assumed the server would own "extract, transform, apply mapping" and delegate creation to Umbraco's server by chaining.
That is not what was built. Creation moved to a C# endpoint (POST /updoc/create-from-source) and the tool triggers it, because a feature that exists only in JavaScript is unreachable to everything that is not Node or a browser — and because a tool that orchestrates five calls is doing work rather than triggering it.
Written up at https://umtemplates.github.io/UpDoc/article-mcp-server/
Refs #129, #131, #133.
A running list of what UpDoc's MCP server could do next, and what it deliberately should not. Not a commitment. Comment as things get built, dropped or reconsidered.
Context: #130 built the server, #132 shipped
create-from-source. Two tools work today. #129 is the umbrella.Worth building
Markdown and web sources for create-from-source
The endpoint refuses both, returning "use the backoffice". The extraction services exist, the workflows exist, and
groupTourWebPageis configured and Ready.Cheapest item here. Same code path with a different extractor, and it removes the obvious "why only PDF?" from the tool's description.
preview-extraction— #131Already open. Runs extraction and returns what would land in each field, creating nothing.
The Content tab does exactly this in the browser, so the pipeline is there. Worth restating why it matters: it lets a session check a PDF before committing, and diagnose a bad mapping without creating and binning a page.
import-report— #133Also open. Which mappings resolved and which did not.
create-from-sourcealready returnsmappedValueCount, but a count without its denominator is not much use — "19" only means something next to "of 19". Turns "did that work?" from a judgement into a fact.Probably worth building
validate-workflowReports a workflow's problems in detail before anything relies on it.
list-workflowsalready surfaces validation warnings, so this is mostly depth rather than new capability. Useful when a session is choosing between workflows, or when an import produced less than expected and the question is whether the workflow or the PDF is at fault.find-mediaSearch the media library for a file, returning size alongside the key.
The specific job is "is this PDF already here, and is it the same revision?". That matters: nine brochures were bulk-seeded ahead of their tours, and one was a stale revision 43 bytes off the live file. A search hit is not proof the right file is there.
Open question whether this belongs in UpDoc's server at all. It is a media-library concern, not an UpDoc one, and Umbraco's server may be the right home.
Not tools, and more valuable than most of them
Publish the server to npm
Nothing above matters much while the server only exists on one machine.
Installing UpDoc's NuGet package does not, and should not, bring a Node process with it — different runtimes, different lifecycles. Consumers would add it via
npxin their MCP config, needing the NuGet package installed and an API user configured.No issue for this yet. Arguably the highest-value item on the page.
Point the backoffice at the endpoint
The create logic now exists twice: C# behind the endpoint, TypeScript in the browser. They agree today. They will not agree forever.
Deliberately deferred — the browser path is what real client work runs on, and it gets switched only after the two are compared side by side on the same PDF.
Release a version containing the endpoint
Tailored Travel's own site runs the NuGet package, so the tool cannot reach it until a release goes out. The mirror works because it references the project directly.
Tagging is Dean's decision alone, as always.
Deliberately not building
create-workflowAuthoring a workflow is a design task, not an import task. The JSON is deliberately AI-readable — a session can already write the files directly, which is the point of storing them as JSON rather than in a database. A tool would add ceremony without adding capability.
publish-document,update-document-properties, and anything else Umbraco already hasReached by chaining to
@umbraco-cms/mcp-dev, which is already configured. Reimplementing them here would be the mistake #132 avoided: tools doing work rather than triggering it.Anything that judges extraction quality
Whether a price caveat landed in the right slot is a function of one project's PDFs and one project's blueprint. UpDoc users fix that by adjusting their own rules and mappings. Not UpDoc's business, and not something a tool can generalise.
Note on #129
The umbrella issue assumed the server would own "extract, transform, apply mapping" and delegate creation to Umbraco's server by chaining.
That is not what was built. Creation moved to a C# endpoint (
POST /updoc/create-from-source) and the tool triggers it, because a feature that exists only in JavaScript is unreachable to everything that is not Node or a browser — and because a tool that orchestrates five calls is doing work rather than triggering it.Written up at https://umtemplates.github.io/UpDoc/article-mcp-server/
Refs #129, #131, #133.