easysociable-mcp

Get / materialize icon

get_icon

Create an immutable icon asset from a confirmed icon ID, returning canonical SVG, asset ID, and content hash. Requires an idempotency key to prevent duplicate creation.

Instructions

Materialize an immutable TemplateIconAsset via Gateway from a confirmed iconId. Call after confirming a candidate from search_icons. Requires idempotencyKey to prevent duplicate creation. Idempotent: repeated calls with identical keys return the existing asset without consuming extra quota. Returns canonical SVG string, iconAssetId, and contentHash.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`iconId`	Yes	Canonical icon identifier confirmed from search_icons (e.g. lucide:arrow-right).
`idempotencyKey`	Yes	Unique idempotency key to prevent duplicate icon asset creation.

Output Schema

TableJSON Schema

Name	Required	Description
`contentHash`	No	SHA-256 hash of the SVG content.
`iconAssetId`	No	Permanent immutable icon asset ID.
`canonicalSvg`	No	Optimized sanitized SVG code.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.17Oct 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "canonicalSvg": {
+      "description": "Optimized sanitized SVG code.",
+      "type": "string"
+    },
+    "contentHash": {
+      "description": "SHA-256 hash of the SVG content.",
+      "type": "string"
+    },
+    "iconAssetId": {
+      "description": "Permanent immutable icon asset ID.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedv0.1.16Oct 5, 2026

changedInput schema / properties / iconId / description

Previous value: -"e.g. lucide:arrow-right"New value: +"Canonical icon identifier confirmed from search_icons (e.g. lucide:arrow-right)."

addedInput schema / properties / idempotencyKey / description

Added value: +"Unique idempotency key to prevent duplicate icon asset creation."

First observedv0.1.13Oct 5, 2026

TDQS

A3.5/5.0

Behavior1/5

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

The description asserts 'Idempotent: repeated calls with identical keys return the existing asset without consuming extra quota', but the annotations declare idempotentHint=false for the same operation. Identical arguments (the required idempotencyKey is part of the arguments) producing no additional effect is precisely the MCP meaning of idempotent, so the description directly contradicts the structured hint. This is a serious inconsistency an agent could rely on incorrectly.

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?

Four tight sentences: purpose first, then workflow, then idempotency/quota behavior, then return shape. Nothing is bloated, though the final sentence enumerating return fields ('SVG string, iconAssetId, contentHash') is partly redundant given an output schema exists.

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?

For a two-parameter tool with a full output schema, the description covers purpose, prerequisite workflow, and the dedup/quota behavior an agent needs. The enumerated return values duplicate the output schema, and the idempotency claim conflicts with the annotations, which is the one substantive gap.

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

Parameters3/5

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

Schema description coverage is 100%, and both parameters are documented in the schema itself, so the baseline is 3. The description restates the purpose of idempotencyKey ('to prevent duplicate creation') and qualifies iconId as 'confirmed', but adds no syntax, format, or behavioral detail beyond what the schema already supplies.

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?

The description states a specific verb+resource ('Materialize an immutable TemplateIconAsset ... from a confirmed iconId'), which correctly clarifies that the misleadingly named 'get_icon' actually creates/returns an asset. It explicitly positions itself against the sibling 'search_icons' (confirm a candidate first, then materialize), so an agent can distinguish the two without opening schemas.

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

Usage Guidelines4/5

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

It gives a clear workflow precondition: 'Call after confirming a candidate from search_icons', which names the alternative tool and the sequencing condition. It lacks explicit when-not conditions or error guidance, so it stops short of a full 5, but the usage context is unambiguous.

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