MCP server

This site ships a Model Context Protocol server, so an AI agent writes Bmage code from what the library actually is rather than from what it remembers. Half of its tools answer from this build's own text - the guides, the XML documentation compiled into the three packages, the source of every page you have been reading. The other half answer by running the real engine on the server: how many bytes a pipeline really produces, whether a size budget is reachable, what the optimiser does, and whether the export still carries the GPS position.

Why an image library needs one

Almost every way of getting image code wrong compiles. There is no warning for a capability probe that runs during prerendering, for a 48 MB buffer nobody disposes, or for an avatar exported with the user's home address in it. Three of the questions this server answers directly:

How big will this really be?

Quality 0.8 is a habit, not a measurement. The bytes depend on the content, the dimensions and the format - and whether a 100 KB budget is reachable at all is something only an encode can say.

RunBmagePipeline

It worked in development, it fails at prerender

A capability probe in OnInitializedAsync, @inject ImageProcessor in a browser app, a registration in only one of a Web App's two containers. All of them compile.

ReviewBmageCode

Is the location still in the file?

MetadataPolicy.Preserve keeps the GPS position the phone recorded. Remove is the default, StripSensitive keeps the camera data - the exported bytes are what decide it.

CompareBmageMetadataPolicies

Connect your agent

The server speaks MCP over HTTP. Point any MCP client at this site's endpoint, at the deployed https://bmage.bitplatform.dev/mcp, or at https://bitplatform.dev/mcp, which serves the tools of every bit platform product - Bmage among them - from one address. The same methods are also plain GET endpoints under /api/mcp/..., which is what the panels further down this page call.

Endpoint

The server you are reading this page on.

One command, from anywhere in your project.

Shell

claude mcp add --transport http bmage https://bmage.bitplatform.dev/mcp

Add it to claude_desktop_config.json, then restart the app.

JSON

{  "mcpServers": {    "bmage": {      "type": "http",      "url": "https://bmage.bitplatform.dev/mcp"    }  }}

Add it to .vscode/mcp.json in the workspace, and it is offered to Copilot in agent mode.

JSON

{  "servers": {    "bmage": {      "type": "http",      "url": "https://bmage.bitplatform.dev/mcp"    }  }}

Add it to .cursor/mcp.json for this project, or to ~/.cursor/mcp.json for all of them.

JSON

{  "mcpServers": {    "bmage": {      "url": "https://bmage.bitplatform.dev/mcp"    }  }}

The pipeline lab

RunBmagePipeline runs a pipeline on the real engine against a generated test image - a photo with sensor grain, a flat-colour screenshot or a transparent graphic - and reports the output size, the bytes for every format and quality, whether a byte budget can be met, the operations the optimiser really runs, and the timings with and without it. The pipeline is the C# you would write; every ImagePipeline method is accepted.

Pipeline

Run settings

Test image

Source size 2400 × 1600

Formats

Qualities

Size budget none

What leaves with the file

CompareBmageMetadataPolicies writes a phone photo - GPS position, serial number, owner, camera, lens, ISO, date and copyright - through the real encoder under each MetadataPolicy, then decodes every file again and reports what is really in it. A privacy decision then rests on the exported bytes, not on what a policy's name suggests.

Review your code

ReviewBmageCode is the pass that closes the loop after an agent writes code. Its rules look for the mistakes that compile cleanly - a capability probe in OnInitializedAsync, @inject ImageProcessor in a browser app, a buffer never disposed, MetadataPolicy.Preserve, WebP with no fallback. The sample below has several on purpose.

Code

@inject ImageProcessor Processor
@inject IImageCapabilityProvider Capabilities
@inject ImageExporter Exporter

@code {
    private ImageCapabilities? _caps;

    protected override async Task OnInitializedAsync()
    {
        _caps = await Capabilities.GetAsync();
    }

    private async Task<EncodedImage> SaveAsync(ImageBuffer photo)
    {
        var thumb = await ImagePipeline.Create()
            .Sharpen(0.3f)
            .MaxSize(400, 400)
            .ExecuteAsync(photo);

        return await Exporter.EncodeAsync(thumb, new ImageExportOptions
        {
            Format = ImageFormat.WebP,
            Metadata = MetadataPolicy.Preserve,
        });
    }
}

One search across everything

An agent rarely knows which corpus holds the answer. SearchBmage covers every guide section, every public member of the three packages, the setup guides, the recipes, the review rules and the demo's sources at once - and every hit carries the exact follow-up call that returns it in full.

Tools

Loading the catalog…

Prompts

Prompts are the workflows: the order to call the tools in for a whole task. They exist because the failure mode of an agent holding a shelf of tools is not ignorance - it is calling them in an order that skips the check which would have caught the bug.

Resources

The same knowledge as URIs, for clients that attach documentation to a conversation up front or let a person browse and pin it. They read the same catalogs the tools do, so neither can go stale relative to the other.

How it stays true

Documentation that is written down separately drifts, and an agent cannot tell a stale answer from a fresh one. So nothing here is written down twice:

The API reference is reflected out of the three shipped assemblies and paired with the XML documentation compiled into them, with each type's namespace and package - Bmage spreads its types over a dozen namespaces, and a wrong using is the commonest way generated code fails to compile.
The guides, the demo pages and their sources are embedded into the server assembly, so the tools keep working from a published deployment and hand out the same text this site renders.
Sizes are measured, not estimated. The pipeline is built by reflection over ImagePipeline's own builder methods and run by the same engine a browser runs, with the managed codecs a headless host has; the budget search is the library's own.
Privacy is read back, not asserted. The metadata comparison decodes the file the encoder wrote, so it reports what is in the bytes.