What Blender MCP Reveals About Building Useful MCP Servers

Most engineering work starts from a familiar setup: someone opens the application you built.

You design the dashboard, decide where the buttons live, and try to surface the important actions clearly. The user picks up a bit of your interface and gets their task done.

More and more, the interesting question is what happens when that same person already has an AI assistant open and simply asks it to handle the task directly.

Does the user really need to open your dashboard at all?

Sometimes the answer is still yes. Swapping a working button for three paragraphs of back-and-forth conversation is not an improvement. But for a number of workflows, forcing someone through your application's navigation is just friction that adds no value.

That is the core reason MCP servers are likely to become more important. Blender MCP is a good illustration of what this can look like in practice, and it also surfaces some less glamorous questions about how you build, maintain, and evaluate these integrations over time.

Those less glamorous questions are exactly what motivated the work on Pulse.

What is MCP, and how do MCP servers work?

MCP is short for Model Context Protocol, an open standard for connecting AI applications to outside tools and data sources. A server built on this standard can expose tools that take action, resources that supply context, and prompts that can be reused. This piece focuses specifically on tools.

The architecture keeps the AI application, referred to as the host, separate from the MCP clients and servers it talks to. The host is responsible for orchestrating the interaction. A client finds out what tools are available by calling tools/list, then triggers a chosen tool with tools/call. The server executes the actual logic and sends back a result. Servers themselves can be hosted locally or accessed remotely.

For a straightforward product integration, the sequence might look something like this:

User asks for something
 → AI application selects an available tool
 → MCP client sends the call
 → Your MCP server checks access and runs the operation
 → Result returns to the AI application

MCP itself has no say in whether the model should reach for a tool, whether the user's request even makes sense, or whether the final response is any good. The protocol wires the components together, but the surrounding application still has to manage how they work as a whole.

Shipping a server also does not guarantee that every AI assistant will pick it up automatically. VS Code, for instance, requires explicit steps to install, configure, and grant trust to an MCP server. There is still a real boundary around integration and permissions that has to be crossed.

What Blender MCP actually demonstrates

The community-built project ahujasid/blender-mcp links AI clients to Blender using a Python-based MCP server paired with a Blender add-on. It can inspect scenes, manipulate objects and materials, and run Python code inside Blender itself. It is worth noting this is a third-party integration, not something Blender ships officially.

Its architecture looks roughly like this:

AI application / MCP client
  ↕ MCP
Python MCP server
  ↕ Project-specific socket connection
Blender add-on
  ↕
Blender scene and operations

That separation is important. MCP governs the interface between client and server. What happens between the server and Blender is entirely up to the implementation. Any MCP server still needs its own mechanism for actually driving the underlying software.

Picture asking an assistant to look over a scene, reposition a few objects, and adjust their materials. With an integration like this, the assistant can carry out operations on the scene directly, rather than just describing which menus to click. Whether the outcome is actually good is a separate matter entirely.

What stands out here is that all the real work still happens inside Blender. The application, its existing feature set, and your ability to inspect what changed remain central.

This pattern seems likely to show up in other kinds of software too: someone requests a specific change, checks the result inside the familiar interface, and switches back to manual work whenever that is quicker.

That feels far more realistic than expecting people to abandon their existing tools and do everything through a chat window instead.

MCP vs APIs: what actually changes?

An MCP server is free to sit on top of an existing API. It can equally wrap a database, a local library, or a purpose-built bridge like the one used in Blender MCP. Adopting MCP does not force you to rebuild your backend just because an AI application is now the one calling it.

What genuinely shifts is that there is now a shared interface for exposing capabilities to any compatible client. Tools are described through definitions that list the available actions and their inputs, so individual client integrations no longer need to each invent their own discovery and calling conventions.

It helps to treat this as a third entry point into a product, sitting next to the existing user interface and the existing API.

Take an inventory system as an example. The business logic already knows how to look up a product, check whether it's in stock, and reserve units of it. Reusing that logic makes far more sense than writing a parallel implementation purely to serve an AI assistant.

That said, the case for MCP isn't unconditional. If you're dealing with a single internal script talking to one known API, calling it directly is probably still the simplest route. MCP earns its keep when you actually need compatibility across several AI clients, or when a reusable tool interface solves a real problem you have. Bolting on another protocol simply because it's currently popular still means one more protocol you now have to maintain.

Building MCP tools is also interface design

This is the step worth slowing down for.

An agent needs to figure out which tool applies to a given task and how to call it correctly. Anthropic's own engineering guidance suggests designing tools around meaningful units of work, giving each one clear boundaries, and evaluating how they perform in practice, rather than exposing every existing endpoint as-is.

For a hypothetical catalog application, a reasonable starting definition might look like this:

{
  "name": "search_catalog",
  "description": "Find products in the authorized catalog by name or SKU. Returns product IDs, names, and availability. Read-only; does not reserve stock.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "minLength": 1 },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20 }
    },
    "required": ["query", "limit"],
    "additionalProperties": false
  }
}

This is meant as an illustration of a tool definition, not a full server implementation or an actual Blender MCP tool. The name, description, and JSON Schema input contract shown here follow the format MCP specifies.

The description spells out what the tool can search, what it returns, and what it deliberately does not do. Its inputs are narrowly scoped. Reserving stock is kept as a separate action on purpose, since it carries different consequences than a simple lookup.

Still, labeling something "authorized" in a description doesn't make it so. The actual enforcement of access controls and input validation has to happen in the implementation. Any action with real consequences also needs a suitable confirmation step. MCP's security guidance for tools addresses these responsibilities directly.

Blender MCP illustrates this tradeoff clearly: its Python execution tool is genuinely powerful, and the project itself warns explicitly about the dangers of letting an assistant run arbitrary code.

For production tools of your own, it's worth starting from the smallest permission set that's actually useful, expanding it only when there's a concrete reason to. It also pays to test the tools against real requests. A description that reads clearly to you is not evidence that an agent will interpret and use it correctly.

How do you know an MCP server is useful?

A working demo only answers one narrow question: does this workflow function at all?

It tells you nothing about whether people keep using the tool, which specific capabilities they rely on, or what fails once real requests move outside the scenario you scripted.

Take a catalog server as an example. You'd want visibility into whether search_catalog actually gets invoked, whether shipping a new release slows down its handler, and whether failures cluster around one particular operation rather than being spread evenly.

Interpretation also requires caution here. A rise in tool calls might reflect genuinely useful work being done. Or it might reflect an agent retrying something that should have succeeded on the first attempt. Raw call counts alone can't distinguish between these two very different situations.

When it comes to monitoring, these are separate concerns and should be tracked separately. Operational metrics cover things like latency and error rates. Product analytics reveal usage patterns and, where you have appropriate identity context, repeat engagement. Task-level evaluation tells you whether the end-to-end workflow actually delivered what the user needed.

This distinction matters because a handler returning successfully is not equivalent to a user task being completed. A handler call can succeed technically and still be followed by a failure during output validation or in the transport layer. Even a technically valid result can turn out to be unhelpful to the person who asked for it.

None of that should get collapsed into a single green status indicator that hides the difference.

Why I am building Pulse for MCP analytics

These questions are what motivated the creation of Pulse, an open-source SDK paired with an optional, separately hosted Cloud service.

You can find the project's public repository at github.com/selimeneserd/pulse-sdk, and starring it there helps others discover it.

It's released under the MIT license. The library watches for completions of MCP tool handlers and can send that metadata to a local destination, to a collector you control, or through an optional OpenTelemetry exporter. Using it does not require signing up for Pulse Cloud, and there's no default Cloud endpoint quietly baked into the integration.

A minimal local setup looks roughly like this:

import { McpServer } from '@modelcontextprotocol/server';
import { createPulse } from '@reviseflow/pulse';
import { createJsonlExporter } from '@reviseflow/pulse-core/jsonl';

const analytics = createPulse({
  environment: 'development',
  exporter: createJsonlExporter({
    path: './catalog-events.jsonl',
  }),
});

const server = analytics.wrapServer(
  new McpServer({ name: 'catalog-server', version: '1.0.0' }),
);

// Register tools on `server`, then connect your existing MCP transport.

This snippet is meant to illustrate instrumentation, not to serve as a full server implementation. It's written against Pulse 0.2.1 and version 2.0.0 of @modelcontextprotocol/server, with Node.js 24.20.0 among the supported runtimes. Simply registering a tool doesn't produce any analytics events on its own; only actual handler invocations do that. When shutting down gracefully, after in-flight handlers have finished, you call await analytics.shutdown({ timeoutMs: 2_000 }).

This particular example targets a TypeScript-based MCP server. There is currently no Python adapter in the SDK that would cover something like Blender MCP.

Pulse Cloud supplies the managed storage layer and dashboard on top of this metadata: tool usage patterns, handler duration, outcome status, and the ability to filter by environment or release. It operates on its own telemetry stream, so your actual tool traffic never gets routed through it.

Sending data to Cloud is opt-in and explicit, done through the HTTP exporter using a collector URL together with a server-side write key. The Cloud product itself is closed source, while the underlying instrumentation layer remains fully open and usable on its own.

Keeping that boundary clear matters. A developer who prefers writing to local JSONL files, or who already has an observability stack, should have every reason to adopt the open-source layer without needing to become a Cloud customer first.

Honest analytics need firm boundaries

Pulse's telemetry deliberately excludes raw prompts, tool arguments, tool outputs, error text, stack traces, and request headers. Even something as simple as a tool name or a technical label deserves scrutiny, since metadata itself can leak sensitive details. Any optional account identifiers are pseudonymous by design, not a guarantee of full anonymity.

Where the measurement stops is just as important as what it collects. Pulse can see that a handler ran and how long it took, but it has no visibility into why the model picked that particular tool, what the user was actually trying to accomplish, or whether the resulting business outcome was any good. It also has no way to record a call that was blocked before ever reaching the handler in the first place.

Delivery of telemetry is best-effort: queues are bounded and retries happen, but nothing guarantees every event arrives. A dropped telemetry event never affects the actual tool result the user receives, but it does mean the data can have gaps. This system is meant for analytics, not for serving as a tamper-proof audit trail.

Given that, it feels more honest to spell out these limits directly than to slap the word "observability" on the feature and leave people guessing about what is and isn't actually being tracked.

Looking ahead

It seems likely that having a genuinely useful MCP integration will turn into another criterion people use when judging a product, alongside the usual ones.

Can an assistant actually reach the functionality a user needs? Are the actions it takes easy to follow and reason about? Can a person step in and review anything consequential before it happens? And does the integration keep functioning once the initial novelty fades?

Blender MCP stands out because it offers a tangible case of an assistant operating real, pre-existing software rather than just talking about it. That direction feels more promising than yet another chatbot whose main job is to describe steps the user could take somewhere else on their own.

None of this means every product needs an MCP server right now, or that traditional graphical interfaces are becoming obsolete. It simply suggests that some workflows might begin inside an assistant and then continue inside the actual application, cutting out some of the manual back-and-forth in between.

Pulse itself might be an early bet, and it's unclear how fast this pattern will become standard practice. Still, the underlying engineering problems seem worth tackling now: designing tools that are genuinely useful, setting sensible permission boundaries, making execution reliable, and being truthful about how those tools get used in practice.

Simply shipping an MCP server won't be enough by itself. The servers worth building are the ones people keep coming back to once the initial curiosity has worn off.

If you're building one yourself, how are you deciding which tools are actually worth keeping?