Ignix

Change the reputation rules

update_reputation_alerts

DestructiveIdempotent

Change the reputation rules; only the fields you pass change. The negative-spike alert fires when negative messages rise above the usual daily average (it needs sentiment analysis, which is OFF until the customer turns it on). For new reviews: alert the team at or below a star rating, and optionally reply automatically at or above one. Keep auto-replies to high ratings (4 stars and up): an automatic text under an angry review reads as a form letter, so those get an alert for a human instead. Choose the team that receives both; with no team it goes to owners and admins. Automatic replies are public: confirm the settings with the user.

Input Schema

Name	Required	Description
`teamId`	No	Team that receives it. Pass an empty string to go back to owners and admins.
`enabled`	No	Turn the negative-spike alert on or off.
`minimum`	No	Negative messages in a day before it is worth warning at all (default 3). Stops a single grumpy comment on a quiet account from firing an alarm.
`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.
`reviewAutoReply`	No	Reply automatically to new reviews, in the brand voice.
`reviewReplyMode`	No	How the reply is written: "ai" in the brand voice, or "template" using the texts in reviewReplyTemplates.
`sentimentAnalysis`	No	Turn sentiment analysis on or off. It is OFF until the customer turns it on: nothing is measured before that, and the negative-spike alert needs it.
`reviewAlertMaxStars`	No	Alert the team when a new review comes in at this rating or below (1-5).
`reviewReplyTemplates`	No	Fixed reply texts, used when reviewReplyMode is "template". Give SEVERAL (up to 5): they are rotated, because the same sentence under fifty reviews is what gives a bot away.
`reviewAutoReplyMinStars`	No	Only auto-reply at this rating or above (1-5). Keep it high: a generated reply to an angry review does more harm than no reply.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 18, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already flag destructiveHint/idempotentHint, but the description adds non-obvious behavior the agent could not infer: automatic replies are PUBLIC, the alert falls back to owners and admins when no team is set, and it explicitly instructs confirming settings with the user. This is exactly the side-effect and safety context annotations can't 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?

The patch-semantics clause is correctly front-loaded and every sentence carries policy or precondition content rather than filler. It is a dense paragraph with nested parentheticals, so it is longer than ideal, but the length is justified by ten parameters and the number of interacting rules.

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?

Covers preconditions (sentiment analysis off by default), routing defaults, public side effects, and confirmation guidance for a ten-parameter mutation tool. With no output schema and no required parameters, an agent might also want to know what the call returns or which account/workspace scope it applies to, which is not addressed.

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 coverage is 100%, so the baseline is 3, but the description adds policy rationale beyond the schema: why 'minimum' exists (a single grumpy comment on a quiet account), why multiple templates are rotated (sameness gives a bot away), and why star thresholds should stay high. Only idempotencyKey and reviewReplyMode details are left entirely to the schema.

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

Purpose4/5

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

States a specific verb and resource ('Change the reputation rules') and adds patch semantics ('only the fields you pass change'), which is the key operational fact. It does not explicitly name the read counterpart get_reputation_alerts, so sibling differentiation is by name inference rather than by statement.

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?

Gives real context for acting: the negative-spike alert requires sentiment analysis, which is OFF by default, and it prescribes when to auto-reply ('4 stars and up') versus alert a human for angry reviews. It never names an alternative tool or says when not to call this one, so it stops short of explicit routing.

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?