AI connector
The AI connector is a Model Context Protocol endpoint you point your own assistant at — Claude, or anything else that speaks MCP. It lets an assistant read your test library and write to it: create and edit test cases, add steps, report bugs, run sessions, describe requirements, read boards.
:::info Plan The MCP server is available from the Starter plan upwards. :::
:::note Recently changed The board and widget tools were renamed, with no alias for the old names — a client still calling one of the left column gets "unknown tool", not a silent redirect to the new one:
| Old tool name | New tool name |
|---|---|
sekee_list_dashboards | sekee_list_boards |
sekee_get_dashboard_data | sekee_get_board_data |
sekee_list_dashboard_metrics | sekee_list_board_metrics |
sekee_create_dashboard | sekee_create_board |
sekee_update_dashboard | sekee_update_board |
sekee_add_dashboard_widget | sekee_add_board_widget |
sekee_update_dashboard_widget | sekee_update_board_widget |
There is no delete tool, under either name — deleting a board or a widget has never been reachable over MCP. If your assistant's tool list still shows the left column, your connector predates this change; reconnect it or ask your client to refresh its tool list. :::
:::note Recently changed The connector can now do nearly everything a person can in Sekee, instead of a part of it: thirty-five new tools and changes to many of the existing ones, listed under Tools. Reconnect your connector, or ask your client to refresh its tool list, to see them — a client keeps the list it was given when it connected.
Two things changed for everyone, not only for people who use an assistant. What an assistant writes in a comment is now marked AI generated, wherever the comment is shown (see below), and mentions in comments are now sent by Sekee itself (see Notifications). :::
The security model, in one paragraph
The connector implements no authorization of its own, and that is the point. A tool call resolves your connector token to your user, mints a 60-second internal token, and makes an ordinary request to the same API the browser uses. Every tenancy check, every role rule and every policy applies exactly as it would to you in a browser, and anything the assistant creates is stamped with you as its author. A rule written only in the connector would be a rule the web app does not have.
Two consequences worth stating plainly:
- An assistant can never do something you could not do. If you are a member, it cannot delete.
- No delete tools exist at all, and the internal allow-list refuses DELETE on product data even if one were added. Deleting a folder cascades through its test cases and steps with no undo, and that is not a thing to hand to a model.
What an assistant writes is marked as its own
Sekee records which writes came from a connector, from the signed token rather than from anything the assistant sends — so a browser cannot claim the mark and a connector cannot shake it off.
| What the assistant did | What Sekee records |
|---|---|
| Created a test case | Marked AI generated, and queued for review |
| Changed a test case a person wrote | Marked AI modified, and queued for review |
| Changed a test case that was approved | The approval is withdrawn and it is queued again |
| Wrote a hand-written requirement's description | The description is marked Written by AI |
| Wrote or edited a comment, anywhere | The comment shows an AI generated badge beside its author |
| Wrote or updated an automation run's AI summary | It appears under AI summary on the run, and only a connector can write or change one |
| Imported test cases | Each marked AI generated, and queued for review |
| Any action Activity records | The same row a person's action gets, attributed to you and marked AI generated |
Testers are told when a case needs reading, by notification and email.
Comments written through the connector say so. The AI generated badge sits beside the author on a test case or automation run comment, on both bug hunt screens and in a session's feed, and the emails that quote a comment — the mention email and the new-comment emails — name the author as (AI generated). The mark is set from the signed token, never from anything in the request, so neither a browser nor an assistant can add it to or remove it from a comment. Editing a comment through the connector marks it too, because the words are then partly the assistant's. Comments that already existed were all written by people and stay unmarked.
:::note Recently changed Comments written by an assistant used to look like the person's own, and the Activity badge read AI. Both now read AI generated. :::
Creating a connection
Settings → AI Connector → New connection.
| Field | Notes |
|---|---|
| Name | Name it after the machine or assistant you will use it from, so you know which to revoke later |
| Access | Standard, or Read only — read only can look at anything you can and change nothing |
Press Create and the same dialog moves on to the setup steps for your assistant, with the token already filled in. The token is shown once: copy it then; Sekee stores only a hash and a short prefix so you can identify the row afterwards. The new connection joins your list when you press Done.
:::note Recently changed The whole setup now happens inside the dialog. Before, clicking New connection showed a "How to connect" panel on the page behind it, and the token and the new row appeared on the page as soon as the connection was made. :::
Revoking
Revoke from the same screen. Every connection shows its prefix, when it was created, and when it was last used — "never used" is a useful thing to notice on a token that has been around for a month.
Revoking asks you to type the connection's name first, then takes effect immediately. You do not need to be an admin to manage your own connectors; they are your credentials, not organization content.
What else ends a connection
Changing your password ends every connection you made before it. So do resetting it with Forgot password?, turning on two-factor authentication, and Sign out everywhere else on Profile → Security — the same moments that sign out your other devices, and for the same reason: they are what you do when you think somebody else has your password, and a connector is a key to your account.
The connection still appears in the list afterwards, but your assistant gets This connector was ended by a password change or a membership change on its next call. Create a new connection, paste it into your assistant in place of the old one, and revoke the old one. An ended connection still counts towards the ten you may hold, so at ten, revoke the old one first.
:::note Recently changed A connector is now private to the person who created it. Nobody else — including an owner or an admin — can see it or revoke it; the admin API Tokens page lists CI tokens only and never shows a connector. Two people may give theirs the same name; a name only has to be unique against your own other connectors, not everyone's.
Removing somebody from the organization, or blocking them, ends their connectors as part of the same action — they stop authenticating immediately, without you needing to find and revoke each one first. :::
What an assistant can reach
Roughly: projects, directories, test cases and steps, shared steps, bug hunts and their cases, steps and issues, sessions with their notes and bugs, comments on all of them, requirements, automation runs and tests, errors, visual testing runs, boards, the dashboard, what you watch, your notifications and the rules below.
An area is only reachable once it has been deliberately added, its paths allow-listed, and its tenancy audited — so a newly built screen is not automatically exposed.
What an assistant cannot do
- Delete anything. The one exception is clearing a test's unstable flag
(
sekee_clear_test_unstable), which removes no data. Steps left out ofsekee_set_test_stepsare removed, as that tool says. - Upload files and attachments.
- Administer the organization: members, invites, roles, policies, Jira settings, API tokens, billing, deleting or exporting the organization.
- Touch your own account: password, two-factor, sessions.
- Read the Activity log.
- Create automation runs, which is the CLI's job. It can write and update a run's AI summary.
- Close and reopen Milestones, or approve AI-written test cases, which stay a person's decision.
What an assistant reads
Everything an assistant is given back is plain text. Rich text — a
description, a charter, a session note, a bug's description, a step's extra
data — comes back as its words, with paragraphs kept. A picture comes back as
[picture] and never as a link, so no signed address for your files is ever
handed to a model. It also means an assistant cannot look at your screenshots:
it names them, and asks you to open them in Sekee.
When an assistant edits a field that holds pictures, it writes [picture]
where each picture should stay, and Sekee puts the original picture back in
that place, so editing around a picture does not lose it. A [picture] it
leaves out removes that picture. What it writes is saved as paragraphs: bold, lists and other formatting in a note are replaced by plain
paragraphs when an assistant edits it, because it never saw them.
Tools
Tools marked read only are the only ones a Read only connection is given. New means the tool did not exist before this release; Changed means it exists and does more, or does it differently, now.
Comments and people
| Tool | What it does |
|---|---|
sekee_list_comments (new, read only) | Searches and reads comments across the whole organization: on test cases, automation runs, bug hunt cases and session notes. Filter by text, kind, the thing commented on, project or author. Newest first; each row says where it is, who wrote it and whether an AI did |
sekee_comment_on_test_case (new) | Comments on a test case, or replies to one of its comments. Plain text |
sekee_comment_on_automation_run (new) | The same for an automation run |
sekee_comment_on_bug (new) | Comments on a bug from a bug hunt or a session, knowing only the bug: its documentId from sekee_list_bugs, or its number with kind (a number alone is refused, because the two kinds are numbered separately). It also answers a comment already on the bug, since a bug's comments are one thread. The comment shows under the bug and on the bug's page. Can mention colleagues. Reconnect the connector to see it |
sekee_comment_on_bug_hunt_case (changed) | Takes an optional step, the step's position from sekee_get_bug_hunt_case, to comment on one step, an optional parentId to reply to a comment on the case, and an optional bugId to comment on one of its bugs; a reply or a comment on a bug stays on its thread's step |
sekee_add_session_note (changed) | Can mention colleagues, reply to a note with parentId, and comment on one of the session's bugs with bugId |
sekee_update_comment (new) | Changes the words of a comment of any kind. Only its author or an admin can, as in the app; nobody is notified by an edit |
sekee_list_people (new, read only) | Finds colleagues by name or username. Returns the id, name and username only: never emails or roles |
To mention someone, give their usernames in mention and write @username in
the text — an assistant that names someone without writing them in is refused.
A name that fits two people is refused with both listed.
Test cases, steps and shared steps
| Tool | What it does |
|---|---|
sekee_get_test_case (changed, read only) | Steps in the order the app shows, each with its id, order, shared step, extra data and custom field values; the issues note; the open bugs known against the case; its comments |
sekee_create_test_case, sekee_update_test_case (changed) | Take scenario and issues |
sekee_duplicate_test_case (new) | The app's Copy and Paste: "name (Copy)" in the same folder or another, with every step, keeping each step's shared step and custom fields |
sekee_import_test_cases (new) | Imports cases the assistant has already parsed (up to 5,000 cases, 300 steps each). Checked first: one refusal imports nothing. Imported cases are marked AI generated and queued for review |
sekee_list_tags (new, read only) | The tags in use, with how many test cases, sessions and bug hunts carry each |
sekee_update_directory (changed) | Also changes a folder's color and position among its siblings |
sekee_add_test_step (changed) | Adds a shared step by id or name, or a step of your own, at a position. A step of your own can have extra data and custom fields; a shared step brings its own text |
sekee_update_test_step (new) | Changes one step's name, expected result, extra data or custom fields. A field not given keeps its value |
sekee_move_test_step (new) | Moves a step to a position; the others shift |
sekee_set_test_steps (changed) | A step given with the id from sekee_get_test_case is updated in place, keeping its shared step, custom fields and pictures. A step without an id is created. Steps left out are still removed |
sekee_list_step_fields (new, read only) | The custom fields your organization added to steps. Says so on a plan without them |
sekee_list_shared_steps (changed, read only), sekee_create_shared_step (changed) | Include a shared step's extra data |
sekee_update_shared_step (new) | Changes a shared step. As in the app, copies already in test cases do not change |
sekee_share_test_step (new) | The app's "Add to shared steps": turns a step into a shared step and links it. Refused when it already is one, or has no name |
Bug hunts
| Tool | What it does |
|---|---|
sekee_get_bug_hunt_case (new, read only) | One case, for running it: its steps with a position and result, the comments and bugs raised on it, the known-issues note, and who it is assigned to |
sekee_set_bug_hunt_step_result (new) | Records passed, failed, blocked or untested for one step. The answer says the case's resulting status |
sekee_set_bug_hunt_case_result (changed) | status is now optional, so a case can be archived (archived) or hidden (hidden, reversible: re-adding the case shows it again) without changing its verdict or touching its Jira issues. assignee is a username |
sekee_report_bug_hunt_issue, sekee_update_bug_hunt_issue (changed) | Take jiraIssueKeys; the first also takes step |
sekee_get_bug (new, read only) | One bug from a hunt or a session: description, severity, status, who reported it, where it was found, attachment names, and the comments on it |
sekee_list_bugs (changed, read only) | Takes milestone — a milestone name, or "none" — for the bugs found in that milestone's bug hunts and sessions, as on the Bugs page |
sekee_update_bug_hunt (changed) | Links and unlinks automation runs; name, description, status, dates and tags now really save (see below) |
:::note Recently changed
sekee_update_bug_hunt sent the hunt's numeric id, which the server could not
use, so it saved nothing and reported success. It saves now, as does the step
update behind a step result.
A step result now moves the case's verdict, on the server, by the same rule as on the execution screen. See Bug hunts. :::
Sessions
| Tool | What it does |
|---|---|
sekee_create_session (changed) | Takes participants. A new session is planned unless a status is given |
sekee_update_session (changed) | Adds participants (addParticipants; there is no removal, as in the app) |
sekee_get_session (changed, read only) | Charter, notes and bug descriptions come back as plain text |
sekee_convert_session_bug_to_note (new) | Turns a session bug into a note on the same session, as Convert to comment does in the app: its status, severity and won't-fix reason are dropped |
sekee_convert_session_note_to_bug (new) | Turns a session note into an open bug on the same session, with an optional title and severity. Only the note's author, or an owner or admin, can |
sekee_set_milestone (changed) | A bug hunt or session can be in several Milestones: naming one adds it and keeps the others; mode: "remove" takes it out of that one, "replace" makes it the only one, and null takes it out of every one. An automation run is in one Milestone, so naming one moves it. Reconnect the connector to see mode |
Automation, errors and visual testing
| Tool | What it does |
|---|---|
sekee_list_automation_runs (changed, read only) | Filters by source, tag, milestone (a name, or "none"), search and a from/to range of days. There is no branch filter |
sekee_list_automation_sources, sekee_list_automation_tags (new, read only) | The sources and tags runs use, A to Z |
sekee_get_automation_run (changed, read only) | One run in full: its threads, tests and failures, and now how long it took and its AI summary, if one is written |
sekee_write_automation_run_summary (changed) | Writes a run's first AI summary: plain text, up to 4,000 characters. A run that already has one refuses it and points to the update tool, so nothing is replaced by accident |
sekee_update_automation_run_summary (new) | Replaces a run's AI summary with new text. The old text is not kept, so an assistant is told to read it first and carry over what still holds. It cannot be emptied. Reconnect the connector to see it |
sekee_get_automation_test (new, read only) | How often a test passed, the manual cases it stands for, its ten latest results |
sekee_unlink_automation_test (new) | Says a test no longer stands for a manual case. Neither is removed |
sekee_get_error (new, read only) | One error in full, with its stack clipped and links removed. Business |
sekee_set_error_defect_type (new) | Product, test, unclassified, or auto to hand it back to Sekee's classifier. Business |
sekee_get_run_insights (new, read only) | The Run insights panel from Automation for one project |
sekee_list_visual_runs, sekee_get_visual_run (new, read only) | Runs with visual snapshots and their counts; one run's snapshots with results. Names and sizes of changes only, never pictures. Business |
sekee_review_visual_snapshot (new) | Approves or rejects one snapshot, with an optional reason. Business |
sekee_approve_visual_run (new) | Approves several snapshots at once, by id or all that are waiting. Approval cannot be undone; an assistant is told to use "all" only when you asked for everything. Business |
Overview, watching and notifications
| Tool | What it does |
|---|---|
sekee_get_dashboard (new, read only) | The Dashboard overview for one project. It leaves out the recent-activity pulse and the getting-started checklist, which are built from the Activity log |
sekee_list_watching (new, read only), sekee_watch, sekee_unwatch (new) | What you are watching, and following or unfollowing a folder, test case, bug hunt, session, Milestone or the unstable tests |
sekee_list_notifications (new, read only), sekee_mark_notifications_read (new) | Your notifications with the unread count; marking some or all read. Their texts are other people's words and are returned as data |
Requirements and projects
| Tool | What it does |
|---|---|
sekee_refresh_requirement (new) | Re-reads one requirement, or the 50 longest-unrefreshed in a project, from Jira. Refreshing also writes the test case links back onto the Jira issues. A hand-written requirement has nothing to refresh |
sekee_create_project (new) | Creates a project, within your plan's limit. Project names can repeat, so other tools ask for the projectId it returns when a name is shared |
Everything else keeps working as before.
Reading long lists
The list tools answer a page at a time: test cases, automation runs, automated
tests, sessions, bug hunts, bugs and errors. Each takes page (from 1) and
pageSize (up to 100, 50 if not given), and each answer carries a
pagination block with the total, the pageCount and, while there is more
to read, the nextPage. An assistant asked about every test case walks the
pages; one asked a narrower question can narrow the list instead —
sekee_list_test_cases takes search (matched against the name and the
description), state, automation, tag and directoryPath, and
sekee_list_errors takes defectType (product, test or unclassified).
limit is still accepted as another name for pageSize, so a client written
against the older tools keeps working.
Directories, shared steps, requirements and unstable tests come back whole.
:::note Recently changed
Until October 2026 most list tools stopped at a fixed size and did not say so.
Test cases came back all at once, every step included, which on a large
project was more than a client would read. Sessions stopped at ten, and
automation runs at twenty-five, taken from every project rather than the one
asked about, with the status filter ignored. Projects stopped at
twenty-five, so a project past the twenty-fifth could not be named at all.
Reconnect a connector, or ask your client to refresh its tool list, for the
assistant to see the page and pageSize arguments.
:::
Rules an assistant reads first
See AI rules. They are standing instructions your organization sets, which the assistant is given before it writes anything.
Practical notes
- The transport is stateless streamable HTTP with JSON responses, not SSE.
- A POST needs
Accept: application/json, text/event-stream, or the SDK answers 406. This is the most common first failure when wiring a client up by hand. - To iterate on a client,
npx @modelcontextprotocol/inspectoris easier to debug against than a desktop assistant.