AI agents

Letting Claude, ChatGPT, Cursor and your own scripts work on tickets, boards and sprints as you, through MCP or the REST API.

AI agents

Note

The MCP server is off in a new workspace until an administrator switches it on under Administration, Modules and features. If you do not see it in yours, ask an administrator.

An AI agent such as Claude, ChatGPT, Cursor or GitHub Copilot in VS Code, or a script of your own, can read and work on tickets, boards and sprints for you. It connects to the workspace in one of two ways:

MCP (the Model Context Protocol) at https://your-workspace.albaticket.com/mcp, which AI applications understand without any setup beyond the address.
The REST API at https://your-workspace.albaticket.com/api/v1, for scripts and for agent tools that take an OpenAPI description.

An agent always acts as you. It sees the projects, tickets and comments you can see and nothing else, and it can do only what you may do: if you cannot move tickets in a project, neither can it. Every change it makes is recorded in the ticket's history under your name, with the agent's name beside it ("Ada Lovelace via Claude Code …"), and people watching the ticket are notified as they would be for any other change.

Only members can connect agents. Customers cannot. Open AI agents from your account settings (Manage AI agents) to find the addresses, make tokens and see what you have connected.

Connecting with OAuth

Most AI applications connect by signing in. You give them the MCP address and they send you to a page in the workspace that asks whether to allow them:

Claude (claude.ai and Claude Desktop): add a custom connector with the MCP address.
Claude Code: run claude mcp add --transport http alba https://your-workspace.albaticket.com/mcp, then /mcp inside Claude Code to sign in.
Cursor: add the server to .cursor/mcp.json as {"mcpServers": {"alba": {"url": "https://your-workspace.albaticket.com/mcp"}}}.
VS Code: add it to .vscode/mcp.json as {"servers": {"alba": {"type": "http", "url": "https://your-workspace.albaticket.com/mcp"}}}.
ChatGPT: where your plan allows custom connectors, create one with the MCP address and OAuth.

Any other application that supports remote MCP servers with OAuth works the same way.

The page names the application and the address it will return you to, and asks what it may do:

Read: see what you can see. It changes nothing.
Read and change: also create, edit, comment on, log time on, move and assign tickets, move cards on boards and plan and run sprints, as far as you may.

Allow only an application you started connecting yourself. The name on the page is the one the application gave itself. When you allow it, the application gets a token that lasts an hour and renews itself while you keep using it. If nobody uses it for 30 days, the application has to ask you again.

Personal tokens

An agent or script that cannot sign in by itself uses a personal token instead. Under Personal tokens, give the token a name you will recognise, choose Read or Read and change, and choose when it expires (30, 90 or 365 days, or never). The token is shown once, when you make it. Copy it then, because it cannot be shown again. Anyone who has it can act as you, so keep it like a password.

Send it with every request as Authorization: Bearer <token>:

curl -H "Authorization: Bearer alba_pat_…" https://your-workspace.albaticket.com/api/v1/me

MCP applications take it as a header too. For example, in Claude Code:

claude mcp add --transport http alba https://your-workspace.albaticket.com/mcp --header "Authorization: Bearer alba_pat_…"

What an agent can do

Through MCP an agent is offered these tools. A connection with read access sees only the ones that read (whoami, list_projects, describe_project, search_tickets, get_ticket, list_boards, get_board, get_backlog, list_sprints, list_activities, get_activity, list_organizations, list_phases, report_hours, search_contacts, get_contact, search_companies, get_company, list_interactions and list_follow_ups).

Tool	What it does
`whoami`	Says who it acts for and whether it may change things
`list_projects`	Lists the projects you can see
`describe_project`	Gives a project's ticket types, priorities, resolutions, components, versions, labels and the people its tickets can be assigned to
`search_tickets`	Finds tickets by words, project, status, assignee, reporter, label or type
`get_ticket`	Reads a ticket with its description, the comments and logged activities you may read, links, sub-tasks and the transitions you can take
`create_ticket`	Creates a ticket
`update_ticket`	Changes a ticket's summary, description, type, priority, assignee, labels, components, parent, due date or custom fields, and a deal's company
`add_comment`	Comments, or adds an internal note in a helpdesk project
`log_work`	Logs time spent on a ticket, with an optional note
`transition_ticket`	Moves a ticket through its workflow
`assign_ticket`	Assigns or unassigns a ticket, with an optional comment
`list_boards`	Lists the boards you can see, with their numbers
`get_board`	Shows a board's columns and cards in board order; a scrum board shows its active sprint unless another is named
`get_backlog`	Shows a scrum board's open sprints with their tickets, then the backlog
`list_sprints`	Lists a board's sprints, closed ones included, and whether you may manage them
`move_card`	Moves a ticket to another column, which moves it through its workflow, and places it before or after another card
`move_to_sprint`	Puts a ticket into an open sprint or back into the backlog
`create_sprint`, `update_sprint`	Adds a sprint, or changes its name, goal or dates
`start_sprint`, `complete_sprint`	Starts a sprint, or completes the active one and moves its unfinished tickets to another sprint or the backlog
`delete_sprint`	Deletes a sprint that has not started; its tickets go back to the backlog
`list_activities`, `get_activity`	Lists your activities, and everyone's where you may see all time, or reads one with its history
`create_activity`, `update_activity`, `stop_activity`, `delete_activity`	Records an activity (with an end, a duration, or running), changes it, stops it or deletes it, under the same rules as the activities page
`list_organizations`, `list_phases`	Names the customers, and the billing periods you may see, with rates only where you may see billing
`report_hours`	Adds the hours of a period up, in total or by day, week, project, customer, label, ticket or member, with amounts where you may see billing
`search_contacts`, `get_contact`	Finds contacts, or reads one with their addresses, numbers, notes and what they have agreed to, where you may see the CRM
`create_contact`, `update_contact`, `add_contact_email`, `add_contact_phone`	Creates a contact, changes one, or adds an address or a number
`search_companies`, `get_company`, `update_company`	Finds companies, reads one with its contacts and deals, or changes its CRM details
`list_interactions`, `log_interaction`	Reads what happened with a contact, a company or a deal, or logs a note, a call, a meeting or a follow-up
`list_follow_ups`, `complete_follow_up`	Lists your open follow-ups, or marks one done

A deal is a ticket in a sales project, so the ticket tools work on it: get_ticket gives its company, value, expected close and people, create_ticket and update_ticket set its fields and its company, and transition_ticket moves it, with the reason when it is lost. An agent never records consent, exports or erases a contact, merges contacts or sends them email: those stay with you, on the pages. What it reads about contacts is personal data, sent to whoever runs the agent, as everything it reads is.

For time, an agent must say which time zone a day or a local time is in (an IANA name such as Europe/Berlin); a time that carries an offset needs none, answers are in UTC, and nothing is read from your account. A label that is a ticket's key links the activity to the ticket, as on the page.

An agent names things as you would: projects and tickets by key, types, priorities, components and resolutions by name, and people as me, by name or by email. It writes descriptions and comments in Markdown. A description imported from Jira is given to it as it was stored and also as Markdown. If it saves a change to that description, the Markdown version is saved, as when you edit it yourself, and the history keeps the original. Boards are named by their number. Moving a card follows the same rules as dragging it: into another column needs permission to move tickets through the workflow, and within a column permission to edit them. A move whose transition asks for a resolution or a comment needs them given with it. Managing sprints needs what it needs on the backlog page: being an administrator, or administering every project the board draws from. An agent cannot create a board or change a board's settings, and nothing can delete a ticket through an agent.

The REST API

Note

The REST API is off in a new workspace until an administrator switches it on under Administration, Modules and features. If you do not see it in yours, ask an administrator.

Scripts and integrations use the REST API at https://your-workspace.albaticket.com/api/v1, with a personal token. It does everything the tools above do. The API documentation on your workspace explains every endpoint, OAuth for applications of your own and the MCP server, has example scripts to start from, and has a reference where you can try requests with your token. The OpenAPI description is at /api/v1/openapi.json.

Revoking access

Connected agents and tokens lists everything that holds access for you: each application you allowed and each personal token, with when it was added and last used. Revoke stops it at once. An application you revoke has to ask you again. Changing your password does not revoke agents. When your account is deactivated, or stops being a member, every agent and token of yours stops working.

Switching the API and MCP on and off

The REST API and the MCP server are two switches under Administration, Modules and features, and both are off in a new workspace until an administrator switches them on. Neither needs the other: with the REST API alone your scripts work and no AI application can connect, and with the MCP server alone it is the other way round. Your AI agents page offers what is switched on and says what is not.

Tokens and connected applications belong to both. While one of the two is off, a token is refused there and works at the other. While both are off, no agent can connect or make a request, and nobody can make a token. Nothing is deleted, so switching one on again brings every connection back.