Skip to main content
Glama
expel-io

Atlassian Goals MCP Server

by expel-io

search_goals

Find Atlassian goals using TQL queries with filters on name, status, owner, and tag. Supports operators like LIKE, =, AND, OR for flexible, targeted search.

Instructions

Search for goals using TQL (Townsquare Query Language). Supports flexible queries with multiple operators.

Supported operators:

  • LIKE: Partial text match. Use _ as single-character wildcard. Example: name LIKE "A.1" or name LIKE "A._"

  • =: Exact match for status/owner. Example: status = on_track

  • AND: Combine conditions. Example: name LIKE "Q4" AND status = on_track

  • OR: Match either condition. Example: name LIKE "A." OR name LIKE "B."

Searchable fields:

  • name: Goal name (use LIKE for partial match)

  • status: Goal status (pending, on_track, at_risk, off_track, done, cancelled)

  • owner: Owner account ID (use = for exact match)

  • tag: Goal tag (use LIKE for partial match)

Examples:

  • Find goals containing "Q4": name LIKE "Q4"

  • Find goals A.1, B.1, C.1: name LIKE "A.1" OR name LIKE "B.1" OR name LIKE "C.1"

  • Find all A.x goals: name LIKE "A."

  • Find on-track Q4 goals: name LIKE "Q4" AND status = on_track

  • Find goals by owner: owner = 712020:user-uuid-here

  • Find goals with a specific tag: tag LIKE "Platform"

  • Find goals with multiple tags (all): tag LIKE "Platform" AND tag LIKE "Q1"

  • Find goals with any of several tags: tag LIKE "Platform" OR tag LIKE "Security"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (1-100, default: 20)
cursorNoPagination cursor from previous response to fetch next page
searchStringYesTQL query string. Examples: 'name LIKE "A.1"', 'status = on_track', 'name LIKE "Q4" AND status = on_track'
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It thoroughly explains the TQL syntax, supported operators, fields, and provides examples, which effectively communicates the query behavior. It stops short of describing response format or error handling, but for a search tool the core behavior is well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with clear sections for operators, fields, and examples. Every sentence carries informative weight, and the use of headers and bullet points makes it scannable. It is appropriately detailed for a query language tool without being redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of TQL and the absence of an output schema, the description covers the essential aspects: what can be searched, how to construct queries, and provided examples. It lacks explicit behavior about pagination or result structure, but the schema covers cursor and limit, so the description is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial meaning beyond the schema by defining each searchable field, explaining operator usage, and giving concrete query examples. This is significantly more than the schema's terse parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search for goals using TQL' with a specific verb and resource. It distinguishes itself from sibling tools like list_goals by emphasizing flexible, operator-based searching, and from get_goal/get_goals by covering multi-condition queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive context on when to use the tool through operator explanations and multiple examples (e.g., filtering by name, status, owner, tag). It does not explicitly name alternatives or exclusion criteria, but the search-focused language and examples imply it is for filtered queries rather than simple listing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/expel-io/atlassian-goals-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server