Provides tools to fetch Atlassian Goals and their latest status updates, search Atlassian Projects, and retrieve detailed project updates including highlights and linked Jira work items.
Allows retrieval of linked Jira work items (epics/issues) with key, summary, status, and URL from Atlassian Project updates.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Atlassian Goals & Projects MCP Server What's the latest status on goal MEWS-3762?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants (Claude, Cursor, etc.) direct access to Atlassian Goals and Atlassian Projects via the Townsquare / Atlas GraphQL API.
Works on macOS and Windows. Each user authenticates with their own Atlassian API token.
Fetch any Atlassian Goal by key (name, owner, status)
Read the latest goal status update including detailed notes
Search Atlassian Projects with optional TQL filters and pagination
Fetch detailed project updates within a date range, including:
Status update summaries
Highlights: decisions, learnings, and risks
Linked Jira work items (epic/issue key, summary, status, URL)
Update notes
Related MCP server: Jira MCP Server
Tool | Scope | Description |
| Goals | Fetch an Atlassian Goal by key (id, name, owner, archived status) |
| Goals | Latest status update + detailed notes for an Atlassian Goal |
| Projects | Search Atlassian Projects with optional TQL filter and pagination |
| Projects | Detailed updates, highlights (decisions/learnings/risks), linked Jira items for one or more Atlassian Projects in a date range |
Node.js 18+ (macOS and Windows)
A personal Atlassian API token (each user creates their own)
Your Atlassian site's Cloud ID
Each user needs their own token. Tokens are personal and should not be shared.
Go to https://id.atlassian.com/manage-profile/security/api-tokens
Click Create API token
Give it a label (e.g. "MCP Server") and click Create
Copy the token immediately — you will not be able to see it again
Your API token inherits the permissions of your Atlassian account. It can read any Goal or Project you have access to.
Visit this URL in your browser (replace yoursite with your actual Atlassian subdomain):
https://yoursite.atlassian.net/_edge/tenant_infoThe JSON response contains a cloudId field — copy that UUID value.
git clone https://github.com/jaimesm-mews/atlassian-goals-projects-mcp.git
cd atlassian-goals-projects-mcp
npm install
npm run buildThe server reads credentials from environment variables set in your MCP client config. You need four values:
Variable | Description | Example |
| Your Atlassian site URL |
|
| Your Atlassian account email |
|
| Your personal API token (from Step 1) |
|
| Site Cloud ID (from Step 2) |
|
Add to your Cursor MCP config (.cursor/mcp.json in your project, or via Cursor Settings > MCP):
macOS:
{
"mcpServers": {
"atlassian-goals-projects": {
"command": "node",
"args": ["/Users/yourname/atlassian-goals-projects-mcp/dist/index.js"],
"env": {
"ATLASSIAN_BASE_URL": "https://mews.atlassian.net",
"ATLASSIAN_EMAIL": "you@mews.com",
"ATLASSIAN_API_TOKEN": "your-token-here",
"ATLASSIAN_CLOUD_ID": "your-cloud-id-here"
}
}
}
}Windows:
{
"mcpServers": {
"atlassian-goals-projects": {
"command": "node",
"args": ["C:\\Users\\YourName\\atlassian-goals-projects-mcp\\dist\\index.js"],
"env": {
"ATLASSIAN_BASE_URL": "https://mews.atlassian.net",
"ATLASSIAN_EMAIL": "you@mews.com",
"ATLASSIAN_API_TOKEN": "your-token-here",
"ATLASSIAN_CLOUD_ID": "your-cloud-id-here"
}
}
}
}Add to your Claude config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"atlassian-goals-projects": {
"command": "node",
"args": ["/absolute/path/to/atlassian-goals-projects-mcp/dist/index.js"],
"env": {
"ATLASSIAN_BASE_URL": "https://mews.atlassian.net",
"ATLASSIAN_EMAIL": "you@mews.com",
"ATLASSIAN_API_TOKEN": "your-token-here",
"ATLASSIAN_CLOUD_ID": "your-cloud-id-here"
}
}
}
}Windows users: use double backslashes in paths (
C:\\Users\\...\\dist\\index.js) or forward slashes (C:/Users/.../dist/index.js).
Once the MCP is connected, ask your AI assistant things like:
Goals:
"Fetch the Atlassian Goal MEWS-3761"
"What's the latest status update on goal MEWS-3762?"
Projects:
"Search for all Atlassian Projects"
"Search Atlassian Projects matching key MEWS-3866"
"Get updates for Atlassian Projects MEWS-3866 and MEWS-4181 from 2026-03-24 to 2026-03-28"
Problem | Solution |
| Check that all 4 |
| Verify your email and API token are correct. Tokens expire if revoked at API token management |
| Check the goal key is correct (e.g. |
Server not appearing in Cursor/Claude | Restart the MCP client after changing config. Check the path to |
npm run dev # Run with tsx (no build step, hot reload)
npm run build # Compile TypeScript to dist/
npm start # Run compiled versionMIT
Fetch an Atlassian Goal by its key. Returns the goal's id, key, name, owner, and archived status.
| Name | Required | Description | Default |
|---|---|---|---|
| goalKey | Yes | Atlassian Goal key, e.g. MEWS-3761 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It states what the tool returns (id, key, name, owner, archived status) and the verb 'fetch' implies a non-mutating operation, but it does not disclose error behavior, required permissions, or any side effects. For a simple read-like tool, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. It avoids unnecessary detail and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simply shaped tool with one parameter, no output schema, and no nested objects, the description provides sufficient context: it explains what is fetched, how to identify it, and what is returned. It does not elaborate on failure scenarios, but that is not critical for this simple fetch operation. Overall, it is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes a description for the only parameter (goalKey) with an example, giving 100% schema description coverage. The tool description itself adds no additional meaning about the parameter beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and clearly identifies the resource ('an Atlassian Goal by its key'), which distinguishes it from sibling tools like get_goal_latest_update and search_projects. It also lists the returned fields, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a known Atlassian goal key, but it does not explicitly mention when not to use this tool or name alternative tools. Given that siblings exist (e.g., get_goal_latest_update), this is a missed opportunity for clearer usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the latest status update (summary + detailed notes) for an Atlassian Goal.
| Name | Required | Description | Default |
|---|---|---|---|
| goalKey | Yes | Atlassian Goal key, e.g. MEWS-3762 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'Fetch' implies a read-only operation, and it discloses the nature of the return content (summary + detailed notes). However, it does not disclose behaviors like what happens if no update exists, error conditions, or response structure. This is adequate but not rich, so a 3 is suitable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately conveys the tool's purpose and content. It includes no filler or redundancy, and the parenthetical (summary + detailed notes) adds value without unnecessary length. This is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one goal key) and no output schema, the description provides a high-level overview of the return content. However, it does not specify the exact structure of the response (e.g., whether it's a single object, includes timestamps, etc.). It is sufficient for basic use but leaves some ambiguity about the return shape, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'goalKey' is fully described in the schema (100% coverage), so the description does not need to add much. The description does not provide extra parameter information, but the schema already explains the format with an example. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the specific resource 'latest status update' for an Atlassian Goal, including the content (summary + detailed notes). This distinguishes it from sibling tools like get_goal (which would fetch the goal itself) and get_project_updates (which operates at the project level). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this tool is for retrieving a specific goal's latest update, which is sufficient context for when to use it. It does not explicitly exclude uses or mention alternatives, but the context is clear enough that an agent would not confuse it with the sibling tools. A 4 is appropriate because it provides clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch detailed updates, highlights (decisions/learnings/risks), linked Jira items, and update notes for one or more Atlassian Projects within a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| dateTo | Yes | End date (YYYY-MM-DD) for the update range | |
| dateFrom | Yes | Start date (YYYY-MM-DD) for the update range | |
| projectKeys | Yes | Array of Atlassian Project keys, e.g. ["MEWS-3866", "MEWS-4181"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature ('Fetch') and enumerates the returned content (highlights, Jira items, notes), but it does not mention permissions, rate limits, pagination, or error behavior. For a read operation this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb 'Fetch' and lists the key output components. Every word adds value; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with three required parameters and no output schema. The description lists the output components, which helps an agent understand what to expect. It could mention the response format (e.g., array) or limitations, but it is largely complete for this basic fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context by saying 'one or more' and 'within a date range', but it does not provide additional syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and clearly identifies the resource: detailed updates, highlights (decisions/learnings/risks), linked Jira items, and update notes for Atlassian Projects. This distinguishes it from sibling tools like get_goal (goals) and search_projects (project search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to fetch updates for one or more projects within a date range. It does not explicitly state when not to use it or name alternatives, but the scope is unambiguous enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Atlassian Projects (Townsquare). Returns project key, name, state, and pagination info. Use searchString for TQL filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Pagination cursor from a previous response | |
| first | No | Max projects to return per page (default 50, max 50) | |
| searchString | No | TQL search string for projects (e.g. 'key IN ("MEWS-3866", "MEWS-4181")' or empty for all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses return fields and TQL filtering, but does not explicitly confirm read-only nature, authentication requirements, or rate limits. 'Search' implies safety, but a direct statement would be stronger.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, three clauses, no filler. It front-loads the verb and resource, then adds return info and a usage hint, making every word valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with optional parameters and no output schema, the description covers the core purpose and return fields. It does not detail pagination mechanics (e.g., how 'after' works) or the behavior of an empty searchString, but the schema fills those gaps, so it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters, including examples and defaults. The description's mention of searchString adds no new semantic detail beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'Atlassian Projects', with the parenthetical '(Townsquare)' specifying the scope. It also lists the return fields (key, name, state, pagination info), which helps distinguish it from sibling tools that focus on goals or project updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this tool is for searching/filtering projects. The description does not explicitly mention when not to use it or name alternative tools for different use cases. Sibling names like get_goal suggest distinctions, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_goalget_goal_latest_updateget_project_updatessearch_projectsScored across 4 tools
Each tool targets a distinct resource and action: goal retrieval, goal update retrieval, project search, and project update retrieval. There is no overlap between goals and projects, and the update tools are clearly scoped to their respective entities.
All tools follow a verb_noun pattern with get_ or search_ prefixes. The compound name 'get_goal_latest_update' is slightly less elegant but still consistent with 'get_project_updates' and does not break the overall naming scheme.
With only 4 tools, the server is lean but appears well-scoped for a read-only informational purpose focused on goals and projects. No tools are redundant, and the count is reasonable for the apparent domain.
The surface has significant gaps: there is no way to list or search goals, and no detailed project fetch endpoint. Users must already know a goal key to retrieve it, which creates a discovery dead end. Mutation and update operations are entirely absent, limiting the server to a narrow read-only subset.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
