MCPサーバー
ルール
届いたメールに何が起きるか。
ルールのツール
| ツール | 機能 |
|---|---|
| listRules | アクティブなコネクション上のすべてのルールを、評価される順に並べ、それぞれが何をするか、何回発火したかとともに示す。 |
| getRule | 1 つのルールの全体。条件、アクション、有効かどうか。 |
| createRule | ルールを書く。届いたメッセージに対する条件と、それに一致するものをどうするか。ルールは無効の状態で作成される。 |
| testRule | 直近 30 日のメッセージのうち、そのルールがどれを捕まえていたか、そしてそれらに何をしていたか。何も変更しない。 |
| setRuleEnabled | 人がルールを読み返したうえで、1 つのルールをオンまたはオフにする。 |
createRule はルールを無効の状態で書き込む。これは、このサーバーが REST API と意図的に異なる唯一の点である。POST /rules の既定は有効である。メールをアーカイブし、ゴミ箱に入れ、転送するルールが、チャットのメッセージ 1 つを根拠に動き始めるべきではない。まずルールを書き、testRule を呼んで、作業相手の人に、その人自身のメッセージのどれが捕まっていたかを見せ、そのうえで setRuleEnabled を頼むこと。
updateRule も deleteRule も並べ替えもないのは、テンプレートの削除がないのと同じ理由である。それらは、チャットウィンドウの中から他人の設定を壊してしまう操作だからだ。削除したルールは元に戻せず、並べ替えは以降のすべてのメッセージの挙動を黙って変えてしまう。3 つとも Settings → Rules と REST API にあり、そこではクリックしているのは人である。
ルールはコネクションに属するので、これらは setActiveConnection が最後に指定したメールボックスに対して動作し、同僚が書いたルールもその 1 つである。1 つのメールボックスは 100 個のルールを持ち、各ルールの条件は最大 20 個、アクションは最大 10 個である。
ここには遡って効くものは何もない。ルールが決めるのは、有効化されたあとに届くメールに何が起きるかであり、すでにあるメールボックスを一掃することはない。testRule は報告するだけで、仕分けはしない。