Goptin

list_tickets

Read-only

List tickets live from Jira / ClickUp with status, assignees, tags, list/sprint, parent, custom fields and linked tickets. Default: open tickets assigned to the user in their current sprint/list. ClickUp: pass list (e.g. "Sprint 102") and scope="anyone" for every ticket in a sprint, include_done for closed statuses.

Input Schema

Name	Required	Description
`tag`	No	Only tickets with a tag containing this text
`list`	No	Sprint / list name fragment or list id (e.g. "Sprint 102"). ClickUp: loads that whole list
`scope`	No	"me" (default): tickets assigned to the user; "anyone": every ticket in the list (ClickUp)
`status`	No	Only statuses whose name contains this text
`account`	No	Which connected account to use: an account_id from list_accounts, or part of its name (e.g. "EverydAI", "Zalo shop"). Omit to search all accounts.
`channel`	No
`assignee`	No	Only tickets with an assignee matching this name (diacritics-insensitive)
`include_done`	No	Include completed statuses
`include_description`	No	Return each ticket's full description (useful to find MR/branch links)

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 3, 2026

addedInput schema / properties / assignee

Added value: +{
+  "description": "Only tickets with an assignee matching this name (diacritics-insensitive)",
+  "type": "string"
+}

addedInput schema / properties / include_description

Added value: +{
+  "description": "Return each ticket's full description (useful to find MR/branch links)",
+  "type": "boolean"
+}

addedInput schema / properties / list

Added value: +{
+  "description": "Sprint / list name fragment or list id (e.g. \"Sprint 102\"). ClickUp: loads that whole list",
+  "type": "string"
+}

addedInput schema / properties / scope

Added value: +{
+  "description": "\"me\" (default): tickets assigned to the user; \"anyone\": every ticket in the list (ClickUp)",
+  "enum": [
+    "me",
+    "anyone"
+  ],
+  "type": "string"
+}

addedInput schema / properties / tag

Added value: +{
+  "description": "Only tickets with a tag containing this text",
+  "type": "string"
+}

First observedNov 2, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description's real contribution is disclosing the non-obvious default filtering (open, assigned to me, current sprint/list) and that data is fetched live, which prevents an agent from assuming it returns everything. It says nothing about result limits, pagination, or what happens when multiple accounts are searched.

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

Conciseness4/5

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

Three sentences, front-loaded with what is listed and the source coverage, then the default behavior, then source-specific widening. Every sentence carries content; the only minor redundancy is repeating the schema's example value for list.

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?

For a nine-parameter, no-required-argument read tool with no output schema, the definition covers the two things an agent cannot infer: the default filter set and the ClickUp-specific widening pattern. The remaining gaps (account resolution across multiple connections, result caps) are modest but real.

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

Parameters3/5

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

Schema description coverage is 89%, so the schema carries the parameter burden and baseline 3 applies. The description restates the meaning of list ("Sprint 102") and scope="anyone" almost verbatim from the schema rather than adding new information, and it never touches tag, status, assignee, account, or channel.

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

Purpose4/5

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

The opening sentence names a specific verb (list) and resource (tickets) across two concrete backends (Jira / ClickUp) and enumerates the returned fields, which clearly separates it from get_ticket. It stops short of naming which sibling to use for the adjacent cases (single-ticket retrieval, task lists), so the differentiation is implied rather than stated.

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

Usage Guidelines3/5

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

It gives the default result set (open tickets assigned to the user in the current sprint/list) and explains how to widen it for ClickUp (pass list plus scope="anyone", include_done for closed). What is missing is any statement of when to prefer this over get_ticket or the other list_* siblings, and no prerequisites are described.

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

All Goptin tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?