--- updatedAt: 2026-09-18T23:39:50.000Z agentTools: projectIndex: https://docs.atono.io/llms.txt --- # Atono MCP tools Once connected, your AI coding assistant can access the Atono tools exposed by the MCP server. These tools define the specific actions the AI can perform within your workspace.
# Setup and context These tools help the AI connect to your Atono workspace and understand its structure—who’s in it, how teams are organized, and how their workflows are defined.
### `atono_configuration` Verifies your connection between Atono and the MCP server. When called, it confirms that authentication succeeded and returns basic workspace details such as the workspace name and number of users.
### `atono_list_users` Retrieves the list of users in your Atono workspace. If you include a `team_id`, the tool limits results to members of that team. The AI might use this when it needs to confirm who’s available for assignment or to reference teammates by name in follow-up actions.
### `atono_list_teams` Lists all teams in your Atono workspace and returns each team’s ID, name, and description. The AI can use this information to determine which team owns a story or bug before performing actions such as creating or moving work.
### `atono_get_team_workflow` Retrieves all workflow steps for a specific team, including their category (To do, In progress, Done, or Won’t do) and whether each step accepts stories, bugs, or new items. This helps the AI understand the team’s workflow before suggesting a move or assignment.
### `atono_get_glossary` Retrieves the entire [product Glossary](https://docs.atono.io/docs/product-knowledge) in TSV format. The AI can use this to check terminology against the glossary before writing or reviewing content, ensuring consistent product language across stories, bugs, and documentation.
# Stories These tools let the AI retrieve, create, or update stories in your workspace—everything from checking acceptance criteria to moving work between steps.
### `atono_get_story` Retrieves a story's full details, including its title, handle, acceptance criteria, workflow step, related context like personas or technical notes, the name of its assigned feature flag, any attachments, and a summary of its subtasks showing how many exist and how many are done or won't do. The AI might call this tool when summarizing progress, checking acceptance criteria, confirming which step a story is in, or checking which flag gates a story's release. The flag's on/off state isn't included, so check the Atono UI for that. Attachment URLs expire after a short time, so re-fetch the story to get fresh ones.
### `atono_list_story_personas` Retrieves all story personas defined in your Atono workspace. The AI uses this tool before creating or updating stories so it can match existing personas wherever possible. If none fits, the AI can use a new persona name and Atono creates it automatically; if it's unclear which persona you mean, the AI asks you to choose. If a new persona name appears misspelled, the AI corrects it and asks you to confirm before applying changes.
### `atono_create_story` Creates a new story in your Atono workspace. It can include a title, user story with persona, acceptance criteria, additional content, and optionally a team assignment. Depending on context and the MCP client, the AI may ask for these details or infer them automatically from the conversation. If no team is specified, the story is added to Story Refinement. Acceptance criteria can be nested, so the AI can create sub-criteria (such as AC #1a) under a top-level criterion. After creating a story, the AI will immediately call `atono_update_ai_context` with DESIGN to record the rationale, tradeoffs, and scoping choices made during authoring. To make this more reliable, include it in your request—for example, 'Create a story and capture the design decisions.'
### `atono_update_story_title` Updates the title of a story. This tool only modifies the title and does not affect the user story content, acceptance criteria, additional content, or any other fields.
### `atono_update_story_content` Updates the user story—the "As a \[`persona`], I want to \[`action`] so that \[`benefit`]"—of a story. This tool only modifies the user story content area and does not affect acceptance criteria or any other fields. If the changes reflect a meaningful shift in scope or persona, the AI may also update the DESIGN AI context to keep product intent in sync.
### `atono_update_story_ac` Replaces all acceptance criteria on a story with a new set. Because this tool overwrites the full list, the AI will always retrieve the story first to capture existing criteria IDs before making changes. Omitting a known ID causes a new criterion to be created in its place, which permanently loses any comments, attachments, and usage metrics associated with the original. If the changes reflect a meaningful shift in scope or persona, the AI may also update the DESIGN AI context to keep product intent in sync.
### `atono_update_story_additional_content` Replaces the additional content of a story—the section below acceptance criteria typically used for background information, technical notes, or other reference material for the team. You can also ask to clear the content from this section.
### `atono_update_story_team` Assigns or unassigns a story to a team. If a team ID is provided, the story is assigned to that team; if not, it becomes unassigned. Use `atono_list_teams` to retrieve valid team IDs.
### `atono_update_story_step` Moves a story to another workflow step within its team. This updates the story’s position in the team’s workflow and affects cycle-time tracking when the step’s category changes.
### `atono_update_story_assignee` Updates or removes the assignee of a story. If a user ID is provided, the story is assigned to that user; if not, it becomes unassigned. The AI may use this tool to keep ownership up to date when tasks shift between developers.
# Bugs These tools let the AI retrieve, create, update, and document bugs within your Atono workspace, helping it report status or summarize fixes as they’re applied.
### `atono_list_environments` Retrieves the list of environments defined in your Atono workspace. Results are returned in the workspace-defined order, consistent with the Environments page. The AI uses this tool to look up valid environments before creating or updating bugs with affected environments.
### `atono_get_bug` Retrieves a bug's full details, including its title, handle, description, reproduction steps, expected and actual behavior, workflow step, team, affected environments, and any attachments. It also includes a summary of the bug's subtasks, showing how many exist and how many are done or won't do. The AI might use this tool to summarize known issues, report progress, or confirm where a bug currently sits in the workflow. Attachment URLs expire after a short time — re-fetch the bug to get fresh ones.
### `atono_create_bug` Creates a new bug in your Atono workspace. The title, summary, reproduction steps, expected behavior, and actual behavior are all required by the tool. If you don't provide all of them, the AI will infer reasonable content from context and create the bug—you can refine the details afterward. Affected environments, assignee, and team are optional. If any provided team, assignee, or environment isn't recognized, the AI will let you know and suggest how to find valid values. On success, it returns the handle of the created bug.
### `atono_update_bug` Updates an existing bug's fields. Any combination of title, summary, reproduction steps, expected behavior, actual behavior, team, and affected environments can be updated in a single call. Fields that are omitted remain unchanged, but any field that's included is replaced in full. For example, the affected environments passed to the tool become the bug's complete list, so adding one environment means the AI must include the bug's existing environments as well. Pass null for `team_id` to unassign the bug from its current team.
### `atono_update_bug_step` Moves a bug to another workflow step within its team. This updates its position in the workflow and contributes to cycle-time tracking when the step’s category changes.
### `atono_update_bug_assignee` Updates or removes the assignee of a bug. If a user ID is provided, the bug is assigned to that user; if not, it becomes unassigned. The AI might use this tool when reassigning work or clarifying ownership during triage.
### `atono_document_bug_fix` Adds a plain-English summary of a fix to the bottom of a bug’s description. This summary may be added automatically by the AI once a fix is completed. For example, you ask the AI to fix a bug. After applying the fix, the AI adds a plain-English summary to the bottom of the bug's description and may also move the bug to the next workflow step (for example, Test) as a separate action.
# Linked items These tools let the AI create links between related backlog items in your workspace.
### `atono_link_bugs_or_stories` Links two backlog items in your Atono workspace. Either item may be a story or a bug. Note: the current MCP toolset does not include a way to retrieve existing links—use the Atono UI to view linked items.
# Subtasks These tools let the AI retrieve, create, update, and delete subtasks on stories and bugs in your workspace.
### `atono_get_subtasks` Retrieves all subtasks for a story or bug, including each subtask's title, description, assignee, workflow step (To do, In progress, Done, or Won't do), and position in the list. The AI uses this tool before updating or deleting a subtask, since it needs the subtask's unique ID first. Returns an empty list if the item has no subtasks.
### `atono_create_subtask` Creates a new subtask on a story or bug. The subtask is added to the end of the list. Only a title is required—description, assignee, and initial workflow step are optional and default to unassigned and To do.
### `atono_update_subtask` Updates one or more fields on an existing subtask—title, description, assignee, or workflow step. The AI uses `atono_get_subtasks` first to find the subtask's ID. At least one field must be provided.
### `atono_delete_subtask` Permanently deletes a subtask from a story or bug. The AI uses `atono_get_subtasks` first to confirm the correct subtask before deleting it.
# Epics These tools let the AI create and manage epics in your workspace.
### `atono_create_epic` Creates a new epic. An epic groups related stories under a shared theme or goal, giving teams a way to track larger bodies of work across timeboxes. Along with a title, the AI can include the epic's user story statements and a description when creating it, and the tool returns the new epic's handle (for example, EPIC-123). The AI might use this tool when a request involves multiple related stories that belong together, or when you explicitly ask to organize work under a higher-level initiative.
### `atono_list_epics` Retrieves a list of epics in the workspace, showing each epic's handle and title, with the most recently updated epics first. You can optionally filter by keyword, which returns only epics whose titles contain that text (case-insensitive). The AI typically uses this to look up an epic's handle before calling another tool that needs it, such as retrieving an epic's details or adding a story to it, or when you refer to an epic by name rather than by handle.
### `atono_get_epic` Retrieves an epic's full details, including its title, description, user story statements, and the stories it contains—each with handle, title, workflow step, and order. The AI might use this to summarize progress across an epic or confirm which stories still need attention.
### `atono_update_epic_title` Updates the title of an epic. Epic titles must be unique across the workspace.
### `atono_update_epic_description` Replaces an epic's description in full. Typically used for implementation notes or supplementary reference material rather than the user story statements themselves.
### `atono_update_epic_user_stories` Replaces all user story statements on an epic with a new set. Because this overwrites the full list, the AI should confirm the complete set of user story statements you want represented before calling it—partial updates aren't supported.
### `atono_add_story_to_epic` Adds an existing story to the end of an epic's ordered list of stories. If the story already belongs to a different epic, it's moved to this one; if it's already in this epic, nothing changes.
### `atono_remove_story_from_epic` Removes a story from an epic. If the story isn't currently assigned to that epic, the tool returns an error rather than silently doing nothing.
# Attachments These tools let the AI upload and retrieve files attached to stories and bugs in your workspace. Attaching a file is a two-step process: first upload the file to a staging area, then attach it to a backlog item.
### `atono_upload_file_url` Retrieves a pre-signed URL for uploading a file to the Atono staging area. The AI uses this URL to PUT the file before attaching it to a story or bug. The staged file is held temporarily until it is attached using `atono_create_attachment`.
### `atono_create_attachment` Attaches a staged file to a story or bug. The file must have been uploaded to the staging area first using `atono_upload_file_url`. An optional position parameter controls where the file appears in the attachment list—`start` adds it at the beginning, `end` (the default) adds it at the end. If the file type is unsupported or exceeds the size limit, the tool returns a descriptive error.
### `atono_get_attachment` Returns information about an attachment, including its file size and content type, along with a download URL for retrieving the file. Use this when you need to access the contents of an attachment already on a story or bug.
# Timeboxes These tools let the AI retrieve timeboxes and their contents, giving it a view of what's planned across your timeline.
### `atono_list_timeboxes` By default, retrieves all timeboxes in your Atono workspace. You can filter results to active timeboxes only—those in progress or scheduled for the future. The AI might use this tool to find a timebox by name before retrieving its contents, or to give you an overview of what's planned across your timeline.
### `atono_list_timebox_items` Retrieves all stories and bugs in a given timebox. You can identify the timebox by UUID or by a search string. If the search matches exactly one timebox, that result is used; if multiple matches are found, the AI will ask you to clarify. Each item is returned with its title, handle, workflow step, team, and content. By default both stories and bugs are included, but either can be filtered out.
# AI context These tools let the AI fetch and update AI context on a backlog item. AI context is used to capture AI-assisted design decisions, investigation notes, and implementation changes during work on a story or bug. For usage guidance, see [AI context](https://docs.atono.io/docs/ai-context). > **Note**: `DESIGN`,`INVESTIGATION`, and `SUMMARY` map to the **Design decisions**, **Technical investigation**, and **Technical changes** in the Atono web application.
### `atono_get_ai_context` Fetches the latest AI context content for a story or bug. Use this at the start of work to pull existing context before investigating or making changes. It can retrieve a DESIGN resource (product and scope decisions recorded during authoring), an INVESTIGATION resource (research notes and findings), or a SUMMARY resource (implementation changes already made).
### `atono_update_ai_context` Creates or updates AI context content for a story or bug. The AI uses this to keep context current as work progresses. The three resource types serve different purposes: * **DESIGN** — Product and scope decisions made during story authoring. Replace or update entries when decisions are revised or superseded. Written by authoring agents; consumed by all agents before and during implementation. * **INVESTIGATION** — Current discoveries, research findings, and constraints. Remove anything superseded or proven incorrect. * **SUMMARY** — Current record of implementation changes. Preserve all entries unless a change has been explicitly reverted. Synthesis should organize and deduplicate—not compress or drop detail.
Always call `atono_get_ai_context` before calling `atono_update_ai_context`. Read the current content, then write a synthesized version—do not append or prepend. Atono retains prior versions automatically.