Singularis

Overview Schema Source Related Servers Discussions Admin

Gaussian blur an image or array

singularis_blur

Idempotent

Apply Gaussian blur to 2D arrays or image files to smooth, denoise, or preprocess data. Specify sigma in pixels; returns blurred array or file path with mass-conservation check.

Instructions

Gaussian blur of a 2D array or an image file (.npy, .png, .jpg) with standard deviation sigma: smoothing, denoising, scale-space, preprocessing. Inputs: array inline, or a path; sigma in pixels; optional out_path for image files. Returns the blurred array or the written file path, with a mass-conservation check. Cost scales with pixels * sigma.

Input Schema

Name	Required	Description	Default
`path`	No
`image`	No
`sigma`	No
`out_path`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.11Oct 19, 2026

changedInput schema / properties / image / anyOf

Previous value: -[
-  {
-    "items": {
-      "items": {
-        "type": "number"
-      },
-      "type": "array"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    "type": "array"
+  },
+  {
+    "items": {
+      "items": {
+        "items": {
+          "type": "number"
+        },
+        "type": "array"
+      },
+      "type": "array"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv0.1.3Oct 15, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (readOnlyHint=false because it can write, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description still adds real value beyond them: the return form (blurred array vs. written path), a mass-conservation check, and cost scaling as pixels * sigma. It leaves out whether an existing out_path is overwritten.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph, correctly front-loaded with what the tool is, followed by inputs, outputs, and cost. The keyword tag list is compact but slightly opaque; nothing is truly wasted, though the sentence is packed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value documentation is not strictly required, and the description still summarizes it. It covers formats, inputs, cost, and output targets for a 4-parameter tool, missing only the path/image interaction rule and failure modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden, and it largely does: it explains that inputs arrive as an inline array or a path, that sigma is in pixels, and that out_path is optional and only meaningful for image files. It does not resolve the relationship between path and image (mutually exclusive? precedence?) or what happens if neither is supplied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource ('Gaussian blur of a 2D array or an image file') and enumerates the accepted formats (.npy, .png, .jpg). No sibling in the list performs a blur, so an agent can identify this tool's niche immediately without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tag list 'smoothing, denoising, scale-space, preprocessing' implies the contexts in which this tool is appropriate, which is more than nothing. However, there is no explicit when-to-use statement, no when-not-to-use guidance, and no named alternative (e.g., fft/fft2 for frequency-domain work) to route between.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.