Ignix

Remember a lasting brand rule

remember_brand_fact

DestructiveIdempotent

Save ONE lasting rule the owner stated for this workspace's content — whether it speaks as a brand, a person or a character (e.g. "my audience is new mums", "our audience is independent barbers in Spain", "never use discounts in our marketing", "always use our booking page as the call to action", "on Instagram keep the tone informal and humorous"). Only what the owner said as a rule (source: user_stated) or accepted when you proposed it (user_confirmed). Never one-off instructions for a single piece ("make this one shorter", "schedule it tomorrow"), and never your own guesses. Kinds audience, tone, cta, keyword, visual, positioning and language (the content language, e.g. "Spanish") hold ONE value per scope. If one already exists, nothing is saved: you get it back as current — show it to the owner and ask whether the new rule REPLACES it (call again with replace: true) or adds to it (merge both into one text and call with replace: true). Never replace without asking. Kinds avoid, terminology, offer, goal and content hold several rules.

Input Schema

Name	Required	Description
`kind`	Yes
`text`	Yes	The rule in the owner's words, at most 280 characters.
`scope`	No	"all" (default) or one network the rule is limited to.
`source`	Yes
`replace`	No	Only after the owner agreed: replace the current rule of a one-value kind (see `current` in the previous answer).
`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 20, 2026

addedInput schema / properties / replace

Added value: +{
+  "description": "Only after the owner agreed: replace the current rule of a one-value kind (see `current` in the previous answer).",
+  "type": "boolean"
+}

First observedOct 17, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare destructiveHint/idempotentHint; the description adds substantial behavior: one-value kinds silently save nothing on conflict and return the existing rule as `current`, and replacement is gated on owner consent. This is exactly the kind of non-obvious side-effect disclosure the annotations cannot carry.

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?

Dense but front-loaded: qualification criteria, then source rules, then exclusions, then conflict handling. Every clause carries information, though the single long paragraph could be broken into a bulleted exclusion/conflict structure for faster scanning.

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

Completeness5/5

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

No output schema exists, and the description covers the return behavior (existing rule returned as `current`), the persistence rules per kind, and the consent gate for replacement. An agent has everything needed to call this correctly and safely.

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

Parameters5/5

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

With 57% schema coverage, the description meaningfully compensates: it explains which `kind` values hold one value vs many, what `source` values mean semantically (owner stated vs owner accepted), what `replace` does and when it applies ('see `current` in the previous answer'), and that scope is per-workspace and per-network. Only workspaceId is left unaddressed.

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 specific verb and resource ('Save ONE lasting rule the owner stated') and immediately bounds what counts as a rule with multiple concrete examples. It sharply distinguishes the tool from the many other brand tools by emphasizing 'lasting rule' vs one-off instructions, so an agent knows exactly which artifact this creates.

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 (owner stated or confirmed it), explicit when-not-to-use ('never one-off instructions for a single piece', 'never your own guesses'), and a concrete conflict procedure (surface `current`, ask the owner, call again with replace: true, never replace unasked). Alternative paths (replace vs merge) are spelled out.

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?