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., "@Image Unblur image preflight MCP check if my 1200x800 PNG fits the upload limits, then plan a Basic pass"
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.
A small local helper for preparing photos before using Image Unblur. The official website performs AI enhancement; this server does not upload, process, or reconstruct image pixels.
The check_image_metadata tool checks a file's format, byte size, and dimensions against the site's published limits: JPG/PNG/WebP, 20 MB, 24 megapixels, and 64–16,384 pixels per side. plan_enhancement suggests a cautious Basic or Pro first pass from a blur description, with reminders to verify faces and text. get_official_links returns the official site, pricing, and contact pages.
For example, before trying to unblur image online, check that a 1200×800 PNG is within the upload limits, then compare any result at full size. The site says Pro can redraw details; a sharper face or letter is not necessarily a more accurate one. Do not use enhancement to claim recovery of intentionally obscured information.
Node.js 20.18.1 or newer:
npm install
npm test
node index.mjsConfigure an MCP client to start node /absolute/path/to/imageunblur-mcp/index.mjs over stdio. No API key or image upload is involved. Limits may change; check the official site before sending a file. MIT license; see LICENSE.
Check only file format, byte size, and dimensions against published Image Unblur limits. No image file is sent.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | ||
| format | Yes | ||
| height | Yes | ||
| sizeBytes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description usefully discloses that no image file is transmitted, clarifying this is a static metadata-only check. It does not disclose return semantics (pass/fail shape), permission needs, or whether limits are static, which are notable gaps for a tool with no 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?
Two short sentences with zero waste, front-loading the check scope and following with the key behavioral constraint that no file is sent.
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 a simple four-parameter validator, the description gives enough to identify what is checked and that no upload occurs. With no output schema or annotations, it should say more about result semantics and the source of the limits, so it remains incomplete but usable.
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 coverage is 0%, but the description names the four checked attributes—format, byte size, width, and height—which map directly to the required parameters. It still does not specify accepted format strings, size units, or dimension units beyond the schema's basic types.
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 ('Check') and the exact attributes checked: file format, byte size, and dimensions, against Image Unblur limits. The scope is clear, though it does not explicitly differentiate from any sibling tool (the listed siblings are unrelated).
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?
Implies use for validating upload metadata before sending an image, reinforced by 'No image file is sent.' However, it gives no explicit when-to-use/when-not guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return allowlisted official product links.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and offers only the word 'allowlisted,' which weakly implies a safe, curated read. It doesn't state that the call is read-only, whether it hits the network, whether results can be empty, or what form the links take.
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 short sentence with no filler, and the key concept lands first. It is arguably under-sized rather than over-sized, but nothing in it is wasted.
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 annotations and no output schema, the description is the only source of truth for behavior and return value, and it says nothing about what the returned links look like, how many, or in what structure. For a tool whose entire value is its output, this is a significant 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 input schema has zero parameters, so the baseline of 4 applies. There is nothing the description could add on parameter meaning, and it correctly implies a no-argument call.
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 gives a verb and resource ('Return allowlisted official product links'), but 'official product links' is underspecified - it doesn't say which products, what the links point to, or how this relates to the tool's title ('Official Image Unblur links'). It is distinct enough from sibling names that no confusion arises, but the purpose is vague.
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 indication of when to call this tool versus check_image_metadata or plan_enhancement, no prerequisites, and no exclusions. The agent must infer from the name alone that this fetches reference links rather than performing any analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose a cautious first model from blur symptoms. It does not inspect or modify an image.
| Name | Required | Description | Default |
|---|---|---|---|
| blurType | Yes | ||
| severity | Yes | ||
| containsTextOrFaces | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the important behavioral fact that the tool does not inspect or modify the image, which is meaningful for a blur-related tool. However, it says nothing about whether the output is a recommendation, a plan object, or guidance text, nor about side effects or determinism.
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 tight sentences with the capability statement first and the scope-limiting disclaimer second; no filler. Brevity is not the problem here—under-specification is.
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 a tool with 0% parameter documentation, no annotations, and no output schema, the description should explain what a 'plan' looks like and how the inputs shape it. It omits both, so an agent cannot predict the response or confidently map inputs to outcomes.
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% and all three parameters are required, yet the description only alludes to 'blur symptoms' generically. It does not explain how severity or containsTextOrFaces influence the chosen model, leaving the agent to guess at the mapping from enumerated inputs to output.
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 phrase 'Choose a cautious first model from blur symptoms' gestures at planning a remediation approach from the blur parameters, and the negative clause clarifies it does not touch pixels. But 'model' is ambiguous (processing model? pipeline?) and the tool name/title 'plan_enhancement' is never reconciled with what is actually produced, so the agent must infer that this is a planning/recommendation 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?
'Cautious first model' weakly implies this is a preliminary step before actual enhancement, but there is no explicit when-to-use guidance, no stated prerequisites, and neither sibling (get_official_links, check_image_metadata) is referenced to clarify ordering or alternatives.
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.0check_image_metadataget_official_linksplan_enhancementScored across 3 tools
The three tools target clearly separate preflight stages: returning official resources, checking metadata limits, and planning a model choice. None overlap in action or output, so an agent can easily select the right tool.
All names use consistent snake_case with a verb_noun structure: get_official_links, check_image_metadata, plan_enhancement. The convention is predictable and readable.
Three tools fit the narrow preflight scope, but the surface is very small and one tool is essentially a static link lookup. It is appropriately scoped rather than excessive, though slightly minimal.
For a preflight-only server, the core checks are covered: resource links, metadata validation, and enhancement planning. There is no actual enhancement execution, which is consistent with the stated scope, but agents may need external follow-through via the official links.
Hosted MCP server for AI photo editing: nothing to install, no desktop photo editor needed.
MCP server for Pixapi: check live credit pricing and balance, then generate images and video.
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server exposing the YourImageShare upload API (upload/list/delete) as tools for AI agents.
