# Simafri Suite (remote · suite-mcp.simafri.com) Professional email, calendar, contacts and files on your own domain. - Trust score: 75/100 (medium) - Change this week: +38 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-10-25 ## Components - remote · `suite-mcp.simafri.com`: 75/100 (this document), [markdown](https://verifymcp.io/servers/com-simafri-professional-email/suite-mcp.md), [page](https://verifymcp.io/servers/com-simafri-professional-email/suite-mcp) ## Channel facts - Endpoint: `https://suite-mcp.simafri.com/mcp` - Transports: `streamable-http` - Auth: `required` - Version: `1.0.0` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-10-25. - **Endpoint Security**: 92/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. - HTTPS is enforced; there's no plaintext access path. - HSTS check failed: the Strict-Transport-Security header is absent. - DNSSEC check failed: this domain isn't protected by DNSSEC. - The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 65/100 - AI-judged instruction clarity (excellent). - Context-footprint check failed: tool/resource definitions use about 14263 tokens (~209/item across 68 items; 68 tools + 0 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 0/100 - Stability not yet verified: not enough scan history yet (needs a 30-day window). - **Tool Coverage**: 100/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 100% of tool parameters carry a description. - **Tool Safety**: 75/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - 0 of 15 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "send_email" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. - An AI judge read all 69 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a current MCP spec version (2026-07-28). **Unverified: 1 category.** A category scored 0 because we could not verify it: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm. ## Install ### How do I install the Simafri Suite MCP server? Simafri Suite is a hosted endpoint at https://suite-mcp.simafri.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add --transport http com-simafri-professional-email 'https://suite-mcp.simafri.com/mcp' ``` ### Cursor ```json { "mcpServers": { "com-simafri-professional-email": { "url": "https://suite-mcp.simafri.com/mcp" } } } ``` ### VS Code ```json { "servers": { "com-simafri-professional-email": { "type": "http", "url": "https://suite-mcp.simafri.com/mcp" } } } ``` ### Codex ```toml [mcp_servers.com-simafri-professional-email] url = "https://suite-mcp.simafri.com/mcp" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "com-simafri-professional-email": { "type": "remote", "url": "https://suite-mcp.simafri.com/mcp", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add com-simafri-professional-email --url 'https://suite-mcp.simafri.com/mcp' --transport streamable-http ``` ### Hermes ```yaml mcp_servers: com-simafri-professional-email: url: "https://suite-mcp.simafri.com/mcp" ``` ### Netclaw ```json { "McpServers": { "com-simafri-professional-email": { "Transport": "http", "Url": "https://suite-mcp.simafri.com/mcp" } } } ``` ### Vellum ```bash assistant mcp add com-simafri-professional-email -t streamable-http -u 'https://suite-mcp.simafri.com/mcp' ``` ### Other ```json { "mcpServers": { "com-simafri-professional-email": { "type": "http", "url": "https://suite-mcp.simafri.com/mcp" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-10-25 (score 75, +38) - [security improvement] Transport: unverified → pass - [security improvement] Injection markers: unverified → pass - [security] First check of Judged manipulation: pass - [security] Authorization: Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. - [functional improvement] MCP protocol: unverified → pass - [functional improvement] Tool coverage: unverified → 100 - [functional] First check of Schema quality: fail - [functional] First check of Schema quality: excellent - [functional] First check of Schema quality: fail - [functional] First check of Destructive annotations: 0 - [functional] First check of Tool coverage: 100 ### 2026-10-12 (score 37) First indexed and scored. ## MCP tools (68) ### `list_conversations` (~803 tokens) List conversations Lists threads, most recently updated first, with the contact, the subject of the mail and the one the team gave the thread ("team_subject", null until rename_conversation gives one), the ticket number of a helpdesk case (what the client quotes, null on somebody's mailbox), the status, where the thread stands in the pipeline, who is handling it, whether a draft is waiting for review, the folder each sits in and whether you have read it. Each thread also says since when its contact has been waiting for our answer ("waiting_since", their oldest message still unanswered, null when nobody waits), and when the last reply came and from which side ("last_reply_at", "last_reply_by"): the two figures a helpdesk queue is watched by, to tell which tickets drag. Name a "box" to read ONE mailbox exactly as its screen shows it: its Inbox by default, another folder on demand, and "unread" for the bold rows alone. Without a "box" it lists the whole account by pipeline status instead, which is a different question: a thread sitting unread in a mailbox has a status like any other, so a list by status is not the list of what is waiting to be read. Input parameters: - `assignee` (string): Narrows to the threads one person is handling, by the email address they sign in with, which list_people gives. The word "none" answers with what nobody has taken yet, which is the queue waiting to b… - `before` (string): Only the threads updated before this instant, as an ISO 8601 timestamp such as "2026-08-31T09:00:00Z". This is how you read past the first page: take the "updated_at" of the last thread the answer ga… - `box` (string): The address of the mailbox to look in, for example "simon@sonentreprise.com": call list_sender_addresses to find it. A support queue is not a mailbox and has no folders. - `brand` (string): The slug of a brand, to narrow to that subdivision of the account: call list_brands to find it. - `channel` (string): The channel the thread runs on. Email is the usual one; "portal" carries the messages written from a client space. - `external_ref` (string): Narrows to the threads of one contact identified by the reference a consumer app gave them, for example "epovest:account:42". - `folder` (string): Which folder of the box to list: one of inbox, sent, drafts, spam, trash, archive, or the id of a folder a person made (list_folders gives them). Defaults to the Inbox, like opening the mailbox does.… - `limit` (integer): How many threads to bring back, 1 to 200. Defaults to 100. - `status` (string): Where the thread stands: "open" for one nobody has taken, "customer_reply" when the contact has written back, "answered" once we replied, "delivery_failed" when our reply bounced, "in_progress" while… - `team` (string): Narrows to the threads handed to one team, by its slug (list_teams gives it), taken by one of its members or not. Narrows the account list, so it does not go with "box". - `unread` (boolean): Only the threads you have not read: the bold rows of the screen, and the same count its Inbox shows. Needs "box". A key that acts for no person has no read state and is told so rather than answered w… ### `search_conversations` (~258 tokens) Search a mailbox Finds the threads of one mailbox by their subject, their text, the people on them or the names of the files they carried, best answer first. Call list_sender_addresses to find the box. This is how you look a mail up when you know a word of it and not where it is. Input parameters: - `box` (string, required): The address of the mailbox to look in, for example "simon@sonentreprise.com": call list_sender_addresses to find it. A support queue is not a mailbox and has no folders. - `folder` (string): Narrows to one folder of the box: one of inbox, sent, drafts, spam, trash, archive, or the id of a folder a person made (list_folders gives them). Left out, the whole box is searched, which is usuall… - `limit` (integer): How many threads to bring back, 1 to 200. Defaults to 100. - `q` (string, required): What is being looked for. Plain words are all required, "a phrase in quotes" is looked for as written, "or" offers an alternative and a leading "-" excludes a word. ### `get_conversation` (~452 tokens) Read a conversation Reads one thread whole: every message in order with its direction, its language and its attachments, the contact fiche, the mailbox the thread arrived through, the draft awaiting review when there is one, and in "notes" what the team left on the thread for each other, oldest first, with who wrote each one. Notes are never part of "messages" and were never sent to anyone. A message the mailbox sent carries "delivery" when the mail system tracked it: per recipient (Bcc included), "state" is "delivered" (accepted by the recipient's server, which says nothing of the inbox or of reading), "deferred" (retried by itself for five days), "bounced", "returned" (accepted, then a non-delivery report came back) or "expired", with the server's own "remote_reply" and a "reason" in plain words. When the thread was filed as it arrived, "filed_reason" says why: "spam_filter" for the filter's verdict, "blocked_sender" for a sender the account had reported, and "spoofed_own_domain" for a mail showing one of the account's own domains whose DMARC check failed, which lands in Spam in a mailbox (mark_not_spam takes it back out) and, on a helpdesk queue, in the Trash with its ticket closed (file_conversation with "inbox" brings it back, open). Read this before writing an answer. To read several threads, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 20 ids to do the same to every one of them in a single call. ### `get_customer_card` (~202 tokens) Read what the account knows about a ticket's customer Reads the customer card of a helpdesk ticket: what the account's own system (its client area, CRM or ERP) knows about the correspondent, asked live by their address, such as their account, their services and when they renew, and what they owe. "status" says "found" with the card, "not_found" when that system does not know them, "unavailable" when it did not answer (ask again later, it says nothing about the customer), "unverified" when it was not asked because the latest message names its correspondent through a Reply-To that nothing authenticates (nothing proves that person wrote, so do not discuss their account by email), and "none" when the account has no such system connected or the thread is somebody's mailbox. Read it before answering a customer about their account, a renewal or an invoice. Input parameters: - `conversation_id` (string, required): The id of the conversation, as list_conversations gives it. ### `get_attachment` (~575 tokens) Read an attachment Reads a file attached to a message and gives back its CONTENT. Text comes back as text, whatever the sender labelled it: a CSV, an XML, a JSON, a Markdown or a log read as text even when they arrive as application/octet-stream. An image comes back as the image itself, a PDF comes back as the text it holds, which is how an invoice, a quote or a contract is read, and a .gz or a .zip is opened to give the text it holds, which is how a DMARC report is read. An office document comes back as its text, which is how a product sheet, a price list or a deck is read: a .docx as its paragraphs and tables in order (headings marked with #, list items with - or their number, tables as Markdown tables), a .xlsx as its cells sheet by sheet, tab-separated, one line per row, dates shown as dates, and a .pptx slide by slide; its pictures follow as images when, with the text, they fit in 1048576 bytes decompressed, and are otherwise listed in "document.images" with their name and size. Its macros are never run. A PDF with no text layer, a scan for instance, says so in "note" and gives the address instead: its pages hold pictures rather than words. What stays binary comes back as its media type, its size and the address to fetch it whole, and says in "note" that its content is not restituable. Above 1048576 bytes (16777216 for an office document), and for an archive holding another archive or for an archive or an office document holding more than 1048576 bytes once decompressed, the answer carries that address rather than the content. Every answer also carries "download_url", and shows it in its last block: the original FILE, byte for byte, under its own name and media type, to GET with no key and nothing to sign, once, within 15 minutes (for example `curl -o fiche.docx ""`). That is the way to turn what you were shown into a file you have: save the photos of a document for a site, hand a PDF to another tool, or fetch a file too large to come back inline. Call get_attachme… Input parameters: - `attachment_id` (string, required): The id of the attachment, as get_conversation gives it on the message that carries it. - `conversation_id` (string, required): The id of the conversation, as list_conversations gives it. ### `create_attachment_upload` (~214 tokens) Open an upload for a file to send Opens an address to send a file to, so that a message can attach it without carrying it. Answers with an upload_id and an upload_url: PUT the bytes to that address in one request (no key, nothing to sign, for example `curl -T report.pdf ""`), then pass {"upload_id": "..."} in the "attachments" of send_email, reply_to_conversation, forward_conversation or approve_draft. This is the way to attach a real document: the inline base64 form asks you to write the whole file out yourself, which a PDF of a few pages overruns. One file per upload, good for one PUT, and it keeps for a day. Input parameters: - `content_type` (string): The media type, for example "application/pdf". Left out, it is read from the bytes when they arrive. - `filename` (string, required): The name the recipient will see, extension included. It is fixed here: the message that attaches the file does not rename it. ### `send_email` (~435 tokens) Send a new email Writes and sends an email to someone, and opens the thread their answer will land in. The text goes out as given, so this is the tool for a message a person has read and approved. With "send_at" it is scheduled instead: nothing leaves until then, and list_scheduled_sends shows it waiting. Input parameters: - `attachments` (array): Files to send along, up to 10 and 7 MiB in total. Each one is named EITHER by "upload_id", a file already pushed to a slot from create_attachment_upload, OR inline by "filename" and "content_base64".… - `bcc`: Who else receives it without the others being told. A blind copy is kept on the sending alone: the thread records the visible recipients only. - `body` (string, required): The text of the message, as the contact will read it. Plain text, in their language. - `cc`: Who else receives it, in copy. Everyone on the mail sees these. - `contact_name` (string): The name of the recipient, recorded on their fiche when we open one. - `from` (string, required): The address to send from: one of the account inbound addresses, or one of the other names of a mailbox, which is what brings the answer back into that mailbox. Call list_sender_addresses to find them… - `send_at` (string): When it should leave, if not now: a date and time with its offset, such as "2026-10-12T08:30:00+03:00", at most a year ahead. Without an offset it is read in the zone of the person this connection ac… - `subject` (string, required): The subject line, up to 255 characters. - `to` (required): Who it is written to. The thread is filed under the first of them. ### `reply_to_conversation` (~441 tokens) Reply in a thread Sends an answer in an existing thread, written by the caller, from the address the thread arrived through. A draft left pending on that thread is superseded, so the contact reads one answer. With "send_at" the answer is scheduled instead, and supersedes that draft only when it leaves. Input parameters: - `attachments` (array): Files to send along, up to 10 and 7 MiB in total. Each one is named EITHER by "upload_id", a file already pushed to a slot from create_attachment_upload, OR inline by "filename" and "content_base64".… - `bcc`: Who else receives it without the others being told. A blind copy is kept on the sending alone: the thread records the visible recipients only. - `body` (string, required): The text of the message, as the contact will read it. Plain text, in their language. - `cc`: Who else receives it, in copy. Everyone on the mail sees these. - `conversation_id` (string, required): The id of the conversation, as list_conversations gives it. - `reply_all` (boolean): true answers everyone the contact wrote to, the people in copy included, minus the account own addresses. Left out, the answer goes to the contact alone. - `send_at` (string): When it should leave, if not now: a date and time with its offset, such as "2026-10-12T08:30:00+03:00", at most a year ahead. Without an offset it is read in the zone of the person this connection ac… - `status` (string): Where the thread stands once the answer is out. Left out, "answered". "in_progress" for an answer that only holds the contact while someone keeps working on the case (an acknowledgement, a request pa… ### `forward_conversation` (~178 tokens) Forward a message Passes the last message of a thread on to someone else: they receive the text quoted under its own header, with the files it carried attached again. Their answer opens a thread of its own, so forwarding to the account support address is how a message reaches the support queue, in that direction only. Input parameters: - `bcc`: Who else receives it without the others being told. A blind copy is kept on the sending alone: the thread records the visible recipients only. - `cc`: Who else receives it, in copy. Everyone on the mail sees these. - `conversation_id` (string, required): The id of the conversation, as list_conversations gives it. - `note` (string): What to say above the quoted message, in your own words. Left out, only the quotation goes. - `to` (required): Who receives the message. ### `list_drafts` (~87 tokens) List drafts Lists the answers Iris has written, with the thread each belongs to, the contact it goes to and the text as it stands. Filter on "pending_review" for the review queue. Input parameters: - `status` (string): Which drafts to list: "pending_review" for those awaiting a decision, "sent" for those that went out, "rejected" for those that were turned down. ### `approve_draft` (~260 tokens) Approve a draft and send it Sends a draft to the contact, with the text as given in "body" when you edited it. The draft keeps the original wording and the sent message keeps what actually left, so the two stay comparable afterwards. Input parameters: - `attachments` (array): Files to send along, up to 10 and 7 MiB in total. Each one is named EITHER by "upload_id", a file already pushed to a slot from create_attachment_upload, OR inline by "filename" and "content_base64".… - `body` (string): The text to send instead of the one Iris wrote. Left out, the draft goes out as it stands. - `draft_id` (string, required): The id of the draft, as list_drafts gives it. - `status` (string): Where the thread stands once the answer is out. Left out, "answered". "in_progress" for an answer that only holds the contact while someone keeps working on the case (an acknowledgement, a request pa… ### `reject_draft` (~69 tokens) Reject a draft Turns a draft down and sends nothing. The thread stays open for another answer, by Iris or by a person. Input parameters: - `draft_id` (string, required): The id of the draft, as list_drafts gives it. - `reason` (string): Why it was turned down, kept with the draft. ### `list_compose_drafts` (~78 tokens) List the messages started and not sent Lists the messages begun on the account addresses and never sent, last written first, with their recipients, subject, text and files. These are unsent texts, not the answers Iris wrote for review, which list_drafts holds. Input parameters: - `address` (string): Narrows to the messages started on one address, from list_sender_addresses. ### `save_compose_draft` (~222 tokens) Keep a message for later Writes down a message being prepared, so it can be finished later from anywhere. Pass "from" to start one; pass its id to write into it again, where the fields you leave out keep the value they had. Saving sends nothing: send_email is what sends. Input parameters: - `bcc`: Who else receives it without the others being told. A blind copy is kept on the sending alone: the thread records the visible recipients only. - `body` (string): The text of the message, as the contact will read it. Plain text, in their language. - `cc`: Who else receives it, in copy. Everyone on the mail sees these. - `draft_id` (string): The id of the unsent message, as list_compose_drafts gives it. - `from` (string): The address it will be sent from, from list_sender_addresses. Needed to start a message, ignored afterwards. - `subject` (string): The subject line, up to 255 characters. - `to`: Who it is written to. ### `delete_compose_draft` (~62 tokens) Discard a message never sent Throws away a message that was started and will not be sent. Nothing was ever delivered, so nothing is lost but the text itself. Input parameters: - `draft_id` (string, required): The id of the unsent message, as list_compose_drafts gives it. ### `list_scheduled_sends` (~120 tokens) List the messages scheduled to leave later Lists the messages given a "send_at" that have not left yet, soonest first: when each leaves (in the zone of the person you act for), from which address, to whom, the subject and text, and the thread an answer goes into. A message that has left is no longer here but in its thread. One that could not leave stays, with state "failed" and the reason, until it is cancelled. Input parameters: - `address` (string): Narrows to the messages leaving from one address, from list_sender_addresses. ### `cancel_scheduled_send` (~100 tokens) Cancel a scheduled message Calls a scheduled message back before it leaves. Nothing is sent and nothing is lost: it becomes an unsent draft again, with its recipients, text and files, whose draft_id the answer gives (delete_compose_draft throws it away). Refused once the message is already leaving. Input parameters: - `scheduled_send_id` (string, required): The id of the scheduled message, as send_email, reply_to_conversation or list_scheduled_sends gives it. ### `set_conversation_status` (~286 tokens) Set the status of a conversation Says where a thread stands, and optionally where it stands in the pipeline. Both are recorded as decided by a person, so a later reading by Iris keeps them. To set the same status on several threads, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. - `deal_stage` (string): Where the thread stands in the pipeline, in your own vocabulary, up to 128 characters. An empty string clears it. - `status` (string, required): Where the thread stands: "open" for one nobody has taken, "customer_reply" when the contact has written back, "answered" once we replied, "delivery_failed" when our reply bounced, "in_progress" while… ### `assign_conversation` (~398 tokens) Say who is handling a thread Puts a colleague's name on a thread of a helpdesk queue: what says, to everyone working that queue, that this one is being dealt with and by whom. It hands over the WORK and not the access, so the thread stays readable by the whole team and nobody loses sight of it. Somebody who does not work that queue is refused rather than named on a thread they cannot open, and so is a deactivated account: put them on the queue first with add_queue_operator. Threads of a mailbox are refused too, a box being held rather than assigned. Name "team" instead of "person" to hand it to a team (list_teams names them): every member who works the queue sees it as theirs to take until one of them does, and a team none of whose members works the queue is refused. unassign_conversation gives the thread back to the queue. To hand several threads to the same colleague or team, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. - `person` (string): The email address the person signs in with, which is not the same thing as the mailbox: it is how the account knows them. - `team` (string): The slug of a team of the account, as list_teams gives it, in place of "person". ### `unassign_conversation` (~215 tokens) Give a thread back to the queue Takes the name off a thread: nobody is handling it, and it goes back to the queue for whoever picks it up. It closes no door, the thread having been readable by everybody working that queue the whole time. Replayed on a thread nobody had taken, it answers the same thing. To give several threads back to the queue, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. ### `add_note` (~305 tokens) Leave an internal note on a thread Leaves a note on a thread for the people who work it: shown on the thread screen beside the messages, marked as internal, and in "notes" of get_conversation. It never reaches the correspondent: it is not sent, not quoted in a reply and not part of the mail. It is where the context goes when you hand a thread to a colleague, what you found, what was agreed, why you stopped. It does not change the status of the thread nor its place in the list. It is signed with the name of the person this connection acts for, when it acts for one. Up to 10000 characters. To leave the same note on several threads, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `body` (string, required): The text of the note, plain text, up to 10000 characters. - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. ### `rename_conversation` (~296 tokens) Give a thread a subject of the team's own Gives a thread a subject that says what it is about, for the people who work it: shown in the lists and on the thread screen in place of the subject of the mail, and in "team_subject" of list_conversations and get_conversation. It is the team's label and never the subject of the correspondent's mail: "subject" stays the one they wrote, every answer still leaves as a "Re:" of it with the ticket number, and their mail client keeps the case as one conversation. Use it on a ticket whose subject says nothing of the request, a form notification ("New message from ...") or a bare order, once you know what is asked: name the request, not the person. One line, up to 255 characters; giving the subject of the mail again, or null, takes the team's away. The renaming is recorded on the thread as a note signed by the person this connection acts for, naming the former subject, and the search finds the thread by both. One subject per thread, so it takes one conversation_id. Input parameters: - `conversation_id` (string, required): The id of the conversation, as list_conversations gives it. - `team_subject` (string, required): The subject the team gives the thread, plain text on one line, up to 255 characters: what is asked, for example "Devis pour un site vitrine" rather than "Nouveau message de Jessica". ### `merge_conversation` (~242 tokens) Merge a ticket into another Merges a helpdesk ticket into another of the same contact, for the client who wrote again beside their case rather than in it. Everything it held moves to the ticket named by "into": its messages, their files, its notes, its drafts. Its number keeps leading to the merged case, so the client's next reply quoting it lands there. The ticket merged away is gone, a note on the one that stays says so (with your reason, when you give one in "note"), and a draft that was waiting on it is set aside. It cannot be undone. Both must be tickets of a support queue you can open, with the same contact; a mailbox thread is refused. Input parameters: - `conversation_id` (string, required): The id of the conversation, as list_conversations gives it. - `into` (string, required): The ticket that stays: its ticket number, as list_conversations gives it in "ticket_number", or its conversation id. - `note` (string): Optional: why both tickets are one request, for the people who work the case. It goes into the note that records the merge: do not leave a second note with add_note. ### `file_conversation` (~733 tokens) File a thread in a folder Files a thread where you say: "archive" puts it away, out of the Inbox and kept for good; "trash" throws it away, where it stays readable and can be brought back; "inbox" brings it back from wherever it was; or "folder_id" files it in a folder a person made (list_folders gives them), which becomes its home. One thread sits in one place, so filing it somewhere takes it out of where it was; a reply brings a thread back to the Inbox without taking it out of its folder. This is the gesture for tidying a mailbox, and "trash" is what "delete this thread" almost always means: nothing is lost for 30 days, after which the Trash deletes it for good, and delete_conversation is the other, immediate and final thing. It does not file spam: report_spam is that gesture, because filing as spam also blocks the sender. A thread of a helpdesk queue has the Trash as its one folder: "trash" throws it away (a spam, a phishing attempt, a prospecting mail nobody answers) and "inbox" brings it back to the view its status belongs to; "archive" is refused there, closing a case being how a queue puts it away. Filing never changes where a thread STANDS: a notice thrown in the Trash is still "open", among what is left to do. Give "status" (and "deal_stage") to settle that in the same gesture, as set_conversation_status would: "trash" with "closed" tidies away what nobody answers, "archive" with "answered" or "closed" puts away an exchange that is over. The status is recorded first, so a status refused leaves the thread where it was, and a thread that then cannot be filed answers that its status was recorded and why it stayed put. To file several threads in the same place, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of re… Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. - `deal_stage` (string): Where the thread stands in the pipeline, in your own vocabulary, up to 128 characters. An empty string clears it. - `folder` (string): Where the thread goes: "archive" to put it away, "trash" to throw it away restorably, "inbox" to bring it back. "spam" is not one of them: call report_spam, which blocks the sender too. Leave it out… - `folder_id` (string): A folder a person made in the thread's box, by its id from list_folders, instead of "folder". - `status` (string): Where the thread stands: "open" for one nobody has taken, "customer_reply" when the contact has written back, "answered" once we replied, "delivery_failed" when our reply bounced, "in_progress" while… ### `list_folders` (~134 tokens) List the folders of a mailbox Lists the folders the people of a mailbox made in it, beside the six every mailbox has (inbox, sent, drafts, spam, trash, archive), each with its id, its name, its full path ("Clients/LCS") and its parent. The ids are what list_conversations, search_conversations and file_conversation take, and what update_folder and delete_folder act on. Input parameters: - `box` (string, required): The address of the mailbox to look in, for example "simon@sonentreprise.com": call list_sender_addresses to find it. A support queue is not a mailbox and has no folders. ### `create_folder` (~168 tokens) Make a folder in a mailbox Makes a folder in a mailbox, at the top or under another folder, to file threads in. Every holder of the box sees it, in the webmail and in their mail client. A name holds no "/", "*" nor "%", is unique among its neighbours, and at the top is none of the six every mailbox has. Input parameters: - `box` (string, required): The address of the mailbox to look in, for example "simon@sonentreprise.com": call list_sender_addresses to find it. A support queue is not a mailbox and has no folders. - `name` (string, required): The name of the folder, 200 characters at most. - `parent_id` (string): The folder it goes under, by its id from list_folders. Left out, it goes at the top. ### `update_folder` (~98 tokens) Rename or move a folder Renames a folder a person made, moves it under another one or to the top, or both; the folders under it follow, and the threads in it stay. What you leave out keeps its value. Input parameters: - `folder_id` (string, required): The folder, by its id from list_folders. - `name` (string): Its new name. - `parent_id` (string|null): The folder it moves under, or null for the top. ### `delete_folder` (~71 tokens) Delete a folder Deletes a folder a person made and the folders under it. Their threads go to the Trash, where they stay readable and restorable for 30 days; nothing is deleted for good. The answer says how many went there. Input parameters: - `folder_id` (string, required): The folder, by its id from list_folders. ### `delete_conversation` (~150 tokens) Delete a conversation for good Deletes a thread and everything it holds: every message, the drafts written on it, and the files that came with them, down to the bytes they were stored as. This is FINAL and there is no trash to fish it back out of, so it is not the gesture for tidying an inbox: file_conversation with "trash" is, and it keeps the thread readable and restorable. Use this only when the record itself must not remain, and when the person asking knows that is what they are asking for. The contact fiche stays, and so does the rest of the correspondence with them. Input parameters: - `conversation_id` (string, required): The id of the conversation, as list_conversations gives it. ### `report_spam` (~237 tokens) Report a thread as spam Moves a thread of a mailbox into its Spam folder, where it stays readable and can be taken back out, and blocks its sender: their next message is filed in Spam too, without anybody being asked again. Spam is emptied 30 days after a thread lands there, and that deletion is final. Threads of a helpdesk queue have no Spam folder and are refused: file_conversation with "trash" throws them away instead. To report several threads, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. ### `mark_not_spam` (~200 tokens) Take a thread out of spam Puts a thread the filter or someone else filed as spam back into the Inbox of its mailbox, and unblocks its sender. A thread that is not in Spam is left where it is, and nothing is unblocked. To take several threads out of Spam, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. ### `unsubscribe` (~290 tokens) Unsubscribe from a mailing list Leaves the mailing list a thread came from (a newsletter, a promotional mailing, a notification list), in the name of the mailbox it arrived in, with what the last message received in the thread offers: one POST to the list's unsubscribe address when it accepts a one-click unsubscription, otherwise a short mail from the box to the list's own address. get_conversation says, in "unsubscribe" on each message, whether it offers a way out ("one_click", "mailto") and when the box took it ("done_at"). Call it once the person has said they want to leave that list: it is their decision about the mail they receive. The answer is {status, method, detail}: "unsubscribed" when the list took the request, "already" when the box had already left from that message (nothing is sent again), "not_offered" when no message of the thread offers a way out, and "refused" when nothing was done, with why in "detail". A thread filed as spam, and a sender that failed DMARC, are refused on purpose: unsubscribing from spam tells its sender that the address exists and is read, and report_spam is the gesture for those. A list that answers with an error is refused with its HTTP code. Input parameters: - `conversation_id` (string, required): The id of the conversation, as list_conversations gives it. ### `list_blocked_senders` (~75 tokens) List the blocked senders Lists the addresses whose mail this account files straight into Spam, most recently blocked first, with the day each was blocked. A block is what report_spam leaves behind, so this is where a rule the account is living under becomes visible again: a sender blocked from a thread long since deleted appears here and nowhere else. ### `unblock_sender` (~100 tokens) Unblock a sender Lets an address write to the Inbox again: their next message is filed like anybody else's. Threads already sitting in Spam stay where they are, a block having always been about the mail still to come; file_conversation with "inbox" is what brings one of them back. An address this account holds no block on answers that there was nothing to lift. Input parameters: - `address` (string, required): The address to unblock, as list_blocked_senders gives it. ### `list_suppressed_recipients` (~100 tokens) List the addresses the account can no longer write to Lists the addresses that pressed "this is spam" on this account's mail, with the day and the label their provider gave it. The account writes to none of them, and it does so SILENTLY: a message to one of these addresses is stopped before it leaves, with no bounce and nothing in the thread to see. So this is the list to read when a mail seems to have gone nowhere and nothing said why. ### `remove_suppression` (~139 tokens) Write to a complaining address again Takes an address off the list above, so this account can write to them again. Weigh it before calling it: the row means a person pressed "this is spam" on mail from this account, and writing to them again is what turns a complaint into a sending reputation the whole platform shares. Call it when there is a reason to believe they want to hear from this account again, said by them, and not merely because a message would not leave. An address holding no suppression answers that there was nothing to lift. Input parameters: - `address` (string, required): The address to write to again, as list_suppressed_recipients gives it. ### `mark_read` (~222 tokens) Mark a thread read Clears the bold on a thread for YOU, exactly as opening it on screen does: a colleague reading the same shared mailbox keeps their own. Reading a thread with get_conversation does not do this by itself, on purpose: fetching a mail is not the same as having read it. A message arriving after this call turns the thread bold again. To clear the bold on several threads, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. ### `mark_unread` (~184 tokens) Put a thread back to unread Puts a thread back among the bold rows, for you alone: what you want to come back to. A colleague sees no change. To put several threads back among the bold rows, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded. Input parameters: - `conversation_id` (required): The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. ### `poll_mailboxes` (~45 tokens) Fetch new mail now Reads the account mailboxes right away instead of waiting for the next scheduled round, and answers with what came in. Call it when you expect a message that has not appeared yet. ### `list_sender_addresses` (~57 tokens) List the addresses you can send from Lists the inbound addresses of the account, each with the block that closes what is written from it and, for a mailbox, the other names that deliver into it. Sending from any of these is what brings the answer back into the mailbox. ### `set_signature` (~99 tokens) Set the signature of an address Writes the block that closes what is written from an address. It belongs to the address, so everyone who writes from it signs the same way; it is put into a message when one is being written, not added behind the sender back. Input parameters: - `address` (string, required): The address to sign for, from list_sender_addresses. - `signature` (string, required): The signature itself, plain text, up to 2000 characters. An empty text removes it. ### `set_archive_on_reply` (~140 tokens) Archive a thread once it is answered Says whether a thread of a mailbox leaves the Inbox for the Archive as soon as the box answers it, whether the answer is written in the webmail, through these tools or in a mail app such as Thunderbird. The thread comes back to the Inbox when a new message arrives in it. A setting of the box: on a box held by several people it moves the thread for all of them. A helpdesk queue refuses it, its threads being worked by status. Input parameters: - `address` (string, required): The mailbox, from list_sender_addresses. - `archive_on_reply` (boolean, required): True to archive answered threads, false to leave them in the Inbox. ### `list_mailboxes` (~65 tokens) List the mailboxes of the account Lists the mailboxes of the account: each one with the people who hold it, the other names that deliver into it and the storage its plan entitles the account to, which every box of it shares. It says who is on a box, never what is in one. ### `add_mailbox_holder` (~149 tokens) Put someone on a mailbox Puts a person of the account on a mailbox, which is what lets them read it. This is how a company takes back the correspondence of someone who has left; it is recorded, and the box shows it to whoever is on it. A box may be held by several people. Input parameters: - `address` (string, required): The address of the mailbox, for example "marie@sonentreprise.com": call list_mailboxes to find it. A support queue is not a mailbox: it has no holder and takes no alias. - `person` (string, required): The email address the person signs in with, which is not the same thing as the mailbox: it is how the account knows them. ### `remove_mailbox_holder` (~131 tokens) Take someone off a mailbox Takes a person off a mailbox: they stop reading it from that moment. Nothing is deleted, and a box left with no holder keeps receiving and keeps everything it holds. Recorded like the other direction. Input parameters: - `address` (string, required): The address of the mailbox, for example "marie@sonentreprise.com": call list_mailboxes to find it. A support queue is not a mailbox: it has no holder and takes no alias. - `person` (string, required): The email address the person signs in with, which is not the same thing as the mailbox: it is how the account knows them. ### `add_mailbox_alias` (~180 tokens) Add another name to a mailbox Points another address at a mailbox: mail sent to it lands in that box, threads there and counts against the storage of the account. An alias has no password, no seat and no storage of its own, and the number one box may carry is limited; list_mailboxes gives the limit and what is already used. Input parameters: - `address` (string, required): The address of the mailbox, for example "marie@sonentreprise.com": call list_mailboxes to find it. A support queue is not a mailbox: it has no holder and takes no alias. - `alias` (string, required): The other address to point at this box, for example "webmaster@sonentreprise.com". It must be free and on a domain of the account: an address already used by the platform, or one on the domain of ano… ### `remove_mailbox_alias` (~105 tokens) Remove a name from a mailbox Stops an address delivering into a box. What already arrived through it stays in the box, and each message still says which name it came in on. Input parameters: - `address` (string, required): The address of the mailbox, for example "marie@sonentreprise.com": call list_mailboxes to find it. A support queue is not a mailbox: it has no holder and takes no alias. - `alias` (string, required): The name to take away, from list_mailboxes. ### `list_people` (~107 tokens) List the people of the account Lists everyone on the account: how they sign in, the rank they hold, and how far they see into the mail. An owner and a manager work every helpdesk queue, which is said as works_every_queue; anyone else works the queues named on them and nothing else. It says who works where, never what any of it holds. A rank is not written from here: for a client of Simafri Suite it is held at the shop and restated at every sign-in. ### `invite_person` (~330 tokens) Invite someone to the account Opens an access for a colleague without a password: an invitation goes to send_to, and whoever opens it chooses the password from its link, which opens for seven days and once. The link is never shown here, you included, and the record names where it went. send_to is the person themselves at an address they already read, or the box of whoever sets up the team's access. A mailbox of this platform is accepted only when an active person already signs in to it; one nobody can open yet, such as the new login itself, is refused, and so is a support queue. Called again for somebody who has not answered yet, it sends a new invitation and the previous link stops opening; somebody who already chose a password is refused, as they change it themselves. Only on an account that is not held at the shop, and never above manager. Input parameters: - `email` (string, required): The address the person will sign in with, for example their new mailbox "zoe@sonentreprise.com". - `locale` (string): The language of the invitation and of their screens. - `name` (string): Their name, as the team will read it. Required for somebody new. - `role` (string): Operator by default: they see the queues and boxes they are given. A manager sees every queue and runs the settings. - `send_to` (string, required): Where the invitation goes: an address the person already reads, or the box of whoever sets up the team's access, for example "it@sonentreprise.com". A box of this platform nobody signs in to yet is r… ### `add_queue_operator` (~167 tokens) Put someone on a helpdesk queue Names a person of the account on a helpdesk queue, which is what lets them work it: they see the threads that arrived on that address, and none of the others. This is how a shared queue is split between colleagues, one department to each. Somebody whose rank already opens every queue is refused rather than given a grant that changes nothing. Input parameters: - `person` (string, required): The email address the person signs in with, which is not the same thing as the mailbox: it is how the account knows them. - `queue` (string, required): The address of the helpdesk queue, for example "contact@sonentreprise.com": call list_sender_addresses to find it. A mailbox is not a queue: it is one person's correspondence and it is handed over wi… ### `remove_queue_operator` (~142 tokens) Take someone off a helpdesk queue Takes a person off a helpdesk queue: they stop seeing its threads from that moment. Nothing is deleted, and a queue nobody is named on keeps receiving and is still worked by the owners and the managers of the account. Input parameters: - `person` (string, required): The email address the person signs in with, which is not the same thing as the mailbox: it is how the account knows them. - `queue` (string, required): The address of the helpdesk queue, for example "contact@sonentreprise.com": call list_sender_addresses to find it. A mailbox is not a queue: it is one person's correspondence and it is handed over wi… ### `list_teams` (~82 tokens) List the teams of the account Lists the teams of the account, the administrative team or the technical one for instance, each with its slug (what assign_conversation and the other team tools take) and who is in it. A team is a way of handing a thread to several people at once; it opens no queue, so a member only ever sees the threads of the queues they work. ### `create_team` (~75 tokens) Create a team Opens a team by its name; its slug comes from the name and never changes, even when the team is renamed. A name too close to one the account already has is refused. Put people in it with add_team_member. Input parameters: - `name` (string, required): The name the team is shown under, 1 to 80 characters. ### `rename_team` (~63 tokens) Rename a team Gives a team a new name. Its slug stays, so every reference to it keeps working. Input parameters: - `name` (string, required): Its new name, 1 to 80 characters. - `team` (string, required): The slug of the team, as list_teams gives it. ### `delete_team` (~62 tokens) Delete a team Deletes a team. The threads handed to it go back to their queue with nobody's name on them; the threads one of its members took stay on that member's name. Input parameters: - `team` (string, required): The slug of the team, as list_teams gives it. ### `add_team_member` (~110 tokens) Put someone in a team Puts a person of the account in a team, whatever their rank. It opens no queue: they see the threads handed to the team only on the queues they already work, which add_queue_operator decides. A deactivated account is refused. Input parameters: - `person` (string, required): The email address the person signs in with, which is not the same thing as the mailbox: it is how the account knows them. - `team` (string, required): The slug of the team, as list_teams gives it. ### `remove_team_member` (~80 tokens) Take someone out of a team Takes a person out of a team. The threads they took from it stay on their name. Input parameters: - `person` (string, required): The email address the person signs in with, which is not the same thing as the mailbox: it is how the account knows them. - `team` (string, required): The slug of the team, as list_teams gives it. ### `list_brands` (~28 tokens) List brands Lists the brands of the account, its subdivisions, each with the slug the other tools take. ### `list_contacts` (~78 tokens) Search the contact book Lists the contacts of the account with their fiche, most recently seen first, and searches them by name, company or address. Input parameters: - `limit` (integer): How many to return, from 1 to 200. Defaults to 200. - `q` (string): What to search for, matched against the name, the company and the addresses. ### `get_contact` (~47 tokens) Read a contact fiche Reads one contact whole: their fiche, the addresses they write from and where each field came from. Input parameters: - `contact_id` (string, required): The id of the contact, as list_contacts gives it. ### `create_contact` (~176 tokens) Open a contact fiche Opens a fiche for someone before any exchange has happened. An address the account already holds returns that contact as it stands, so calling it twice keeps one fiche. Input parameters: - `address` (string): Their postal address. - `company_name` (string): The company they write for. - `contact_title` (string): Their role there, for example "Directrice generale". - `email` (string, required): Their email address, which identifies the fiche. - `language` (string): The language to write to them in, as a code such as "fr", "en" or "mg". - `name` (string): The name of the person. - `phone` (string): Their phone number, as they gave it. - `project_type` (string): What they came for. - `sector` (string): The sector they work in. ### `update_contact` (~187 tokens) Enrich a contact fiche Writes the fiche fields you pass, and leaves the others as they are. What is written here is recorded as coming from a person, which keeps a later reading by Iris from overwriting it. Input parameters: - `address` (string): Their postal address. - `company_name` (string): The company they write for. - `contact_id` (string, required): The id of the contact, as list_contacts gives it. - `contact_title` (string): Their role there, for example "Directrice generale". - `language` (string): The language to write to them in, as a code such as "fr", "en" or "mg". - `name` (string): The name of the person. - `phone` (string): Their phone number, as they gave it. - `project_type` (string): What they came for. - `sector` (string): The sector they work in. ### `list_knowledge` (~47 tokens) List the knowledge docs Lists the playbook docs of the account with their full content: this is the material Iris reads before drafting, and the place to look when an answer needs to say what the house does. ### `create_knowledge` (~177 tokens) Add a knowledge doc Adds a doc to the playbook Iris reads, scoped to the brands and addresses you give it. Use it to record a price list, an argument that works or a rule to follow, once, where every future draft will find it. Input parameters: - `addresses` (array): The inbound addresses this doc applies to, from list_sender_addresses. An empty list applies it to every address of the brands above. - `brands` (array): The brand slugs this doc applies to, from list_brands. An empty list applies it to the whole account. - `content` (string, required): The doc itself, in Markdown. This is the text Iris reads before drafting. - `sort_order` (integer): Where the doc sits in the reading order, lowest first. - `title` (string, required): The title of the doc, unique in the account. ### `update_knowledge` (~181 tokens) Rewrite a knowledge doc Writes a doc whole, keeping the previous version dated in its history. Send the title and the content each time, plus the brands and addresses it applies to. Input parameters: - `addresses` (array): The inbound addresses this doc applies to, from list_sender_addresses. An empty list applies it to every address of the brands above. - `brands` (array): The brand slugs this doc applies to, from list_brands. An empty list applies it to the whole account. - `content` (string, required): The doc itself, in Markdown. This is the text Iris reads before drafting. - `doc_id` (string, required): The id of the doc, as list_knowledge gives it. - `sort_order` (integer): Where the doc sits in the reading order, lowest first. - `title` (string, required): The title of the doc, unique in the account. ### `delete_knowledge` (~90 tokens) Remove a knowledge doc Takes a doc out of the playbook, with every version it ever had. This is FINAL and there is no trash: Iris stops reading it from the next draft on. A doc that is merely out of date is better rewritten with update_knowledge, which keeps the previous version dated in its history. Input parameters: - `doc_id` (string, required): The id of the doc, as list_knowledge gives it. ### `get_settings` (~120 tokens) Read the account settings Reads the settings of the account, starting with whether an incoming message has Iris draft an answer on its own. "own_domain_spoofs" says what the account does with a mail that shows one of its own domains and fails DMARC: "filed" when such a mail goes to Spam (to the Trash, closed, on a helpdesk queue) as it arrives, and "exempt_senders" for the addresses of the account that keep arriving normally although they fail. It is read here, and the support team changes it on request. ### `set_auto_draft` (~80 tokens) Set automatic drafting Says whether an incoming message has Iris draft an answer on its own. With it off, a draft is written when someone asks for one from the inbox, which is what keeps the model spend where you put it. Input parameters: - `auto_draft` (boolean, required): true has every incoming message drafted, false leaves the drafting to a person, from the inbox. ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-simafri-professional-email/suite-mcp#diagnostics ## Score history - 2026-10-25: 75 - 2026-10-24: 37 - 2026-10-23: 37 - 2026-10-22: 37 - 2026-10-21: 37 - 2026-10-20: 37 - 2026-10-19: 37 - 2026-10-18: 37 - 2026-10-17: 37 - 2026-10-16: 37 - 2026-10-15: 37 - 2026-10-14: 37 - 2026-10-13: 37 - 2026-10-12: 37 ## Common questions ### What is the Simafri Suite MCP server? Simafri Suite is an MCP server listed in the public MCP registry as com.simafri/professional-email. Professional email, calendar, contacts and files on your own domain. This page covers its hosted endpoint (https://suite-mcp.simafri.com/mcp). ### Is the Simafri Suite MCP server safe to use? Simafri Suite scores 75 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm. ### What tools does the Simafri Suite MCP server expose? Simafri Suite exposes 68 tools: list_conversations, search_conversations, get_conversation, get_customer_card, get_attachment, and 63 more. Their descriptions and schemas cost roughly 12,599 tokens of context every time the server is loaded. ### Does the Simafri Suite MCP server require authentication? Yes. Simafri Suite asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything. ### Is the Simafri Suite MCP server still maintained? Simafri Suite is still listed as active in the MCP registry. We last reached this channel on 25 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced. ## Links - Remote endpoint: https://suite-mcp.simafri.com/mcp - Website: https://www.simafri.com/en/suite/ - Changelog RSS feed: https://verifymcp.io/servers/com-simafri-professional-email/suite-mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/com-simafri-professional-email/suite-mcp.json - HTML version of this page: https://verifymcp.io/servers/com-simafri-professional-email/suite-mcp