Someone mentions a ticket. When the call ends, you ask Sayli about it, and it reads the ticket and answers from what is actually there. Then it proposes the follow-up, and you decide whether it goes.
Tools, after the call
MCP connections let Sayli use your other tools once a call is over. A read tool pulls a real ticket or a real doc into an answer. A write tool drafts an issue or a page for you to send.
Tools are switched off for the whole recording, on purpose: deciding whether to call one, and waiting for it, costs more time than a live answer can afford. They run afterwards, when Sayli writes the brief and when you ask a question about a finished call.
The presets
Five connect in one tap from Connections.
| Tool | Connect with | Who can use it |
|---|---|---|
| Linear | A pasted key | See below |
| GitHub | A pasted key | See below |
| Jira | Atlassian sign-in | The person who connected it |
| Confluence | Atlassian sign-in | The person who connected it |
| Notion | Notion sign-in | The person who connected it |
Who else can use a connection depends on how it was made, so nobody's account is driven by a colleague's questions:
HubSpot and Salesforce presets are built for after-call lookups and are not on the Connections page yet.
Read now, write on confirm
Read tools run while Sayli answers a post-call question or writes a brief. They ground a reply in a real ticket or a real doc, so the answer reflects what your tools hold, not a guess.
Write tools work differently. Sayli proposes them in the brief, with the change spelled out. They run only after you confirm.
A write tool is always a proposal first. You read it, then you decide. Sayli never posts, edits, or sends on its own.
Connect one
Pick the tool. The card says what Sayli will read and write before you approve anything.
Linear and GitHub take a pasted key. Jira, Confluence and Notion send you through the provider's own sign-in.
Settings, then Developer, lists every MCP server your team connected: test one, pause it, or run a tool by hand.