MCP 서버
규칙
메일이 도착할 때 무슨 일이 일어나는지.
규칙 도구
| 도구 | 하는 일 |
|---|---|
| listRules | 활성 연결의 모든 규칙을 평가되는 순서대로 보여 주며, 각 규칙이 무엇을 하는지와 몇 번 발동했는지도 함께 알려 줍니다. |
| getRule | 규칙 하나의 전체 정보: 조건, 동작, 켜져 있는지 여부. |
| createRule | 규칙을 작성합니다. 도착하는 메시지에 대한 조건과, 거기에 맞는 메일에 무슨 일이 일어나야 하는지를 지정합니다. 규칙은 비활성 상태로 생성됩니다. |
| testRule | 지난 30일 동안의 메시지 중 어떤 것이 이 규칙에 걸렸을지와 그것들을 어떻게 처리했을지 보여 줍니다. 아무것도 바꾸지 않습니다. |
| setRuleEnabled | 사람이 내용을 확인한 뒤 규칙 하나를 켜거나 끕니다. |
createRule은 규칙을 비활성 상태로 작성하는데, 이는 이 서버가 REST API와 의도적으로 다르게 동작하는 유일한 지점입니다. POST /rules는 기본값이 활성입니다. 메일을 보관하거나 휴지통으로 보내거나 전달하는 규칙이 채팅 메시지 한 줄을 근거로 동작을 시작해서는 안 됩니다. 먼저 규칙을 작성하고, testRule을 호출해 대신 일하는 사람에게 그들의 실제 메시지 중 어떤 것이 걸렸을지 보여 준 다음에야 setRuleEnabled를 요청하세요.
updateRule도 deleteRule도 순서 변경도 없는데, 템플릿 삭제가 없는 것과 같은 이유입니다. 이것들은 채팅 창 안에서 다른 사람의 설정을 망가뜨리는 작업입니다. 삭제된 규칙은 복구할 수 없고, 순서 변경은 이후 모든 메시지의 처리 방식을 조용히 바꿉니다. 세 가지 모두 설정 → 규칙과 REST API에 있으며, 거기서는 사람이 직접 클릭합니다.
규칙은 연결에 속하므로, 이 도구들은 setActiveConnection이 마지막으로 지정한 메일함에 대해 동작하며 동료가 작성한 규칙도 그중 하나입니다. 메일함 하나는 규칙 100개를 담고, 각 규칙에는 조건 최대 20개와 동작 10개를 둘 수 있습니다.
여기 있는 어떤 것도 소급 적용되지 않습니다. 규칙은 활성화된 뒤에 도착하는 메일에 무슨 일이 일어날지를 정할 뿐, 이미 쌓여 있는 메일함을 훑지 않으며, testRule은 처리하는 것이 아니라 보고합니다.