AccountHub

update_message_alert

Destructive

Update a 定期依頼 (name, Gmail query, watched accounts, AI instruction, run_hour, enabled). Get the id from list_message_alerts. instruction and run_hour must be changed together (an instruction requires a run_hour, and vice versa). Same query conventions as create_message_alert.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "update_message_alert"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Rule id from list_message_alerts.
`name`	No
`query`	No	New Gmail-syntax query.
`enabled`	No	false pauses the request; true resumes it.
`accounts`	No
`run_hour`	No	Local hour (0-23). Change together with instruction.
`instruction`	No	What the AI should do when it runs. Change together with run_hour.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026
- removedInput schema / properties / instruction / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / instruction / type
```
Added value: +[
+  "string",
+  "null"
+]
```
First observedOct 2, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, so the safety profile is partially covered. The description adds the meaningful coupling rule (instruction and run_hour must change together), but leaves a critical mutation question unanswered: whether omitted fields are preserved or cleared on a partial update.

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?

Three compact sentences that front-load the scope, then the id source, then the coupling constraint. The parenthetical field list and untranslated 定期依頼 are minor noise but don't bloat the text.

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

Completeness3/5

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

For a 7-parameter destructive update with no output schema, the description covers scope and one coupling rule but omits partial-update semantics and what the response contains. Adequate but with a real gap for a mutation tool.

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 coverage is 71%, so most parameters are already documented. The description restates the instruction/run_hour pairing and points to create_message_alert for query syntax, but adds no format detail for accounts, name, or the null-handling of instruction.

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 (Update) and resource (定期依頼 / message alert rule), and enumerates the updatable fields, so the agent immediately knows the operation's scope. It references the sibling create_message_alert for query conventions, but doesn't explicitly contrast against it the way a 5 would.

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?

Tells the agent to obtain the id from list_message_alerts and to follow create_message_alert's query conventions, which is concrete routing. It doesn't say when to prefer update versus delete/create, and gives no exclusions, so it stays below a 5.

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

All AccountHub 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?