Connecting via the MCP Server

The ISO Mate MCP server lets AI assistants and developer tools manage your workspace over a single endpoint, using a scoped API token for authentication. You connect your client to the /api/mcp endpoint of your ISO Mate API and authenticate with a token you create under Profile > API Tokens. Every request runs through the same permissions and account scoping as the REST API.

Step 1: Create an API token

1. Open the profile menu in the top toolbar and choose API Tokens.
2. Click Create Token.
3. Give the token a descriptive Token Name, for example “Kiro Integration”.
4. Choose the Account the token is scoped to, and optionally set an Expiry Date. Leave the date empty for a non expiring token.
5. Under Permissions, select the scopes your tool needs. Permissions are grouped by module, and you can search by name or use the quick select buttons to toggle an action, such as view, across every group at once.
6. Click Create Token and copy the token immediately. It is shown only once.

You can only grant scopes you hold yourself. If you select a permission your own roles do not give you, creating the token is refused and the missing permissions are listed.

These tokens are intended for MCP connections with AI tools such as Kiro, Claude Desktop, and Cursor.

Step 2: Configure your MCP client

Add the ISO Mate server to your client configuration. The exact format depends on your tool, but you always need two things:

• Server endpoint: the /api/mcp path of your ISO Mate API, which accepts JSON-RPC 2.0 requests over POST
• API token: the token you created in Step 1, sent as a bearer token

How authentication and scoping work

The server speaks JSON-RPC 2.0. When your client calls tools/list, it receives only the tools your token’s scopes allow, and a tools/call is enforced against the same scope before it runs. Each token is bound to a single account, so a tool never reaches data in another account.

A token never exceeds the access of the person who created it, and it does not keep access they later lose. Its scopes are checked against your permissions as they stand at the time of each request, not as they stood when the token was made. If one of your roles is taken away, every token you created loses whatever that role provided, straight away, with no need to revoke or reissue anything. The practical consequence is that adjusting somebody’s roles is enough to adjust what their tools can do.

Token and request limits

An account can hold a limited number of active tokens at once. The allowance is generous for an account with an active subscription, and much smaller for one without, since an unsubscribed account has less reason to run many integrations. If you reach it, revoke a token you no longer use to make room for a new one. Expired and revoked tokens do not count towards it.

Requests are limited in two ways at once. Each token has its own per minute allowance, and the account as a whole has a larger one that all of its tokens draw on together. Creating more tokens therefore does not increase the total your account can send. A busy tool can reach either limit, and the response tells you how long to wait.

Normal use never approaches these. They exist so that one runaway integration cannot crowd out the rest of your workspace. If a legitimate workload needs more headroom, contact support.

An active subscription is required for writes

If your account’s trial has expired, or its subscription has ended, MCP tools can still read but can no longer write. Listing, getting, and reporting operations keep working, so an integration that pulls data for a dashboard is unaffected. Anything that creates or changes a record is refused with a message saying a subscription is required.

Connecting and discovery are deliberately left alone, so your client still completes its handshake and tools/list still answers. That way a tool can report the reason it cannot act rather than failing without explanation.

Subscribing restores writes immediately, with nothing to reconfigure and no need to reissue the token. An account whose payment is being retried keeps full access throughout, so a card that has simply expired never interrupts an integration.

Available tool providers

Once connected, a broad set of tool providers is available. Most use a resource and operation pattern, for example resource “issues” with operation “create”. The tools your token can see depend on the scopes you granted.

• DevOps: issues, sprints, releases, user stories with their acceptance criteria, and features, including comments and lifecycle actions like start, close, release, and archive
• Quality Assurance: test cases with their steps, test cycles, the folders that organise both, test executions with per step results and defect links, and test environments
• Task Management: tasks and recurring tasks with priorities, due dates, and assignees
• Incident Management: incidents through their lifecycle, status transitions, role based assignment, linked tasks and notes, and audit logs
• Compliance: frameworks, requirements, controls, policies, procedures, evidence, attestations, risks, and the Compliance AI tools
• Help Desk: tickets with replies, notes, watchers, entity links and tags, plus canned responses
• Notes: notes, note folders, and note tags
• Custom Objects: object types and their entries, with schema validation
• Diagrams: create structured diagrams on the canvas
• Workflow Automation: workflows, executions, metrics, templates, versions, import and export, and configuration discovery
• Editor AI: generate and refine rich text for supported editor contexts
• Calendar: calendar events, including recurring events
• Sales: leads, opportunities, and deals
• Contacts: your contact directory with search by email, name, or company
• Reports: chart ready distribution and trend data for compliance, sales, feedback, and calendar
• Billing: read only access to subscription status, plan, trial, and invoices
• Platform analytics: platform wide feature usage metrics, available to super admins

User and role management is deliberately not available over MCP. Adding people to an account, changing their roles, and creating organizations are console actions only, so a connected tool can never alter who has access to your workspace.

Build a traceable QA record set over MCP

A connected tool can build a complete, linked QA record set without anyone opening the console. Coverage in the traceability matrix comes from links, so the order matters:

1. Create a feature, then the user stories under it, passing an acceptance criteria array so each story carries its criteria as structured records rather than as prose in its description.
2. Create the test cases, passing a steps array so each case has real actions and expected results from the start. Steps can also be added, edited, reordered, duplicated, and deleted afterwards.
3. Link each case to the acceptance criterion it verifies. Linking at the criterion rather than at the story is what makes partial coverage visible, so a story with three criteria and one test reads as partly covered rather than as covered.
4. Create a test cycle and add the cases to it. Adding a case is what creates its test run, and you can pass an environment in the same call to stamp every run it creates.
5. Run them. Start a run, record a Pass, Fail, or Blocked result for each step, then complete it. The overall result is derived from the step results, so one failed step fails the run. Link any defect you raise to the run that found it.
6. Read the cycle progress back, so your tool confirms what it built rather than assuming.

Test cases and test cycles can be filed into folders over MCP as well. Read the folder tree to resolve a folder, then pass it when you create the record. Deleting a folder that still holds records or subfolders is refused unless you ask for it explicitly, and when you do the records move to the top level instead of being deleted along with the folder.

One thing to watch: updating a story’s acceptance criteria replaces the whole set, so include every criterion you want to keep. A criterion left out of the array is deleted, along with any test links it carried.

Reference issues by project key

The DevOps tools let you reference an issue by its project key instead of its UUID. For example, pass BUG-7 to the get operation to retrieve that issue directly, or use the project key filter to list every issue with a given prefix.

Parameters are validated, never ignored

Where a tool documents a parameter, it either uses it or tells you it cannot. A name the tool does not recognise is refused, and the error lists the names it does accept, so a typo fails immediately rather than returning a success for a record that quietly dropped part of what you sent. If a call succeeds, everything you sent was used.

Security notes

• Each token is scoped to a single account, so data from other accounts is never accessible.
• Grant only the scopes your tool needs, following least privilege.
• A token cannot carry more access than the person who created it holds, either when it is created or afterwards. Removing one of their roles immediately narrows every token they made.
• Billing is read only over MCP. Billing management is refused when the token is created, so it cannot be attached to one even by somebody who holds that permission.
• An account can hold only a limited number of active tokens, and all of them share one account wide request allowance, so extra tokens cannot be used to raise throughput.
• Writes require an active subscription or trial. Reads and tool discovery continue to work, so a lapsed account can still be read from while it is put right.
• Revoke a token immediately from the API Tokens page if it is ever compromised. Revoking is still the right move when the token itself has leaked, since narrowing permissions only limits what it can reach, it does not invalidate the token.

Related articles

• Tracking and Resolving Incidents
• Using Reports and Analytics
• Managing Users and Roles
• Managing Your Subscription

Feature

• MCP Server Integration

Want to drive ISO Mate straight from your AI tools? Start your free 14-day trial.