Ignix

Edit the learned posting style

update_brand_style

Destructive

Hand-edit the posting style Ignix learned from the brand's published posts — the writing VOICE (how it writes captions) and/or the VISUAL guide (colours with their role, layout, typography, treatment, recurring elements, what to avoid) — for the whole workspace (scope 'general') or for one account (scope 'account' + accountId). This is what content generation uses to write and design posts, not how Sparky replies to customers (that is update_brand_profile). A hand edit is kept: the weekly re-learning does not overwrite it. In visual, the fields you pass replace the current ones and the rest stay; colors replaces the whole palette. Read get_brand_profile (postingStyle) first and show the human the change before saving. reset ('voice', 'visual' or 'both') drops the hand edit and re-learns from the posts right away — that re-learns with the AI right away; it is free (no credits), but tell the user their hand edit will be replaced.

Input Schema

Name	Required	Description
`reset`	No	Go back to the learned style instead of editing (re-learns now; may spend AI credits).
`scope`	No	Default 'general'.
`voice`	No	New description of how the brand writes. Replaces the current one. Empty string clears it. Max 2000.
`visual`	No	Visual guide fields to change.
`accountId`	No	With scope 'account': the account (list_accounts).
`workspaceId`	No
`idempotencyKey`	No	Optional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

removedInput schema / properties / confirm

Removed value: -{
-  "description": "true ONLY after the user said yes to the quote (what it does and the credits). Without it nothing runs and nothing is charged.",
-  "type": "boolean"
-}

First observedOct 17, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description goes further by disclosing what survives ('a hand edit is kept: the weekly re-learning does not overwrite it') and precise replacement scope ('the fields you pass replace the current ones and the rest stay; colors replaces the whole palette'). It loses a point for an internal inconsistency: the description says reset 'is free (no credits)' while the reset parameter schema says 'may spend AI credits'.

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?

Front-loaded with the core purpose and constrained to a single dense block, but the long parenthetical enumerations of visual fields add length that the schema already carries. Each sentence broadly earns its place, with minor redundancy.

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 7-param mutation tool with nested objects and no output schema, it covers purpose, scope, replacement semantics, the reset path, and the read-before-write prerequisite. It leaves workspaceId and the idempotency retry contract to the schema, which is acceptable but not exhaustive.

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?

With 86% schema coverage the baseline is 3, but the description adds real meaning beyond the schema: scope 'general' = whole workspace vs. 'account' + accountId = one account, and that colors replaces the entire palette. The credits conflict on reset slightly muddies otherwise strong parameter guidance.

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+resource ('Hand-edit the posting style Ignix learned') and immediately bounds its two axes (writing VOICE vs. VISUAL guide). It explicitly distinguishes itself from the nearest sibling, update_brand_profile, so an agent can route correctly without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('content generation uses this... not how Sparky replies to customers — that is update_brand_profile'), an ordering prerequisite ('Read get_brand_profile (postingStyle) first and show the human the change before saving'), and the reset branch with its consequence and cost. Both the alternative and the excluded case are named.

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

All Ignix tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?