Skip to main content
Glama

Count Tracker issues

tracker_issues_count
Read-onlyIdempotent

Count issues matching a Tracker query-language string or field-value filter. Use it to measure queue backlog, confirm open-item totals, or validate search criteria before fetching issues.

Instructions

Count of issues matching a query-language string or a filter.

body.query is a TQL string, body.filter a field → value object; an empty body counts every issue the caller can see. E.g. {"body": {"filter": {"queue": "QUEUE", "status": "open"}}}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesTyped request body for ``POST /issues/_search`` and ``POST /issues/_count``. Give ``query`` (the query language) or ``filter`` (field name → value); a body with neither matches every issue the caller can see. ``extra="allow"`` passes the API's other keys (``keys``, ``queue``, ``order``) through.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.122.1
    • addedInput schema / properties / body
      Added value: +{
      +  "additionalProperties": true,
      +  "description": "Typed request body for ``POST /issues/_search`` and ``POST /issues/_count``.\n\nGive ``query`` (the query language) or ``filter`` (field name → value); a body with neither\nmatches every issue the caller can see. ``extra=\"allow\"`` passes the API's other keys\n(``keys``, ``queue``, ``order``) through.",
      +  "properties": {
      +    "filter": {
      +      "anyOf": [
      +        {
      +          "additionalProperties": true,
      +          "type": "object"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "Field name → value the issues must have."
      +    },
      +    "query": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "A query-language string."
      +    }
      +  },
      +  "type": "object"
      +}
    • removedInput schema / properties / query
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "TQL query; takes precedence over ``queue`` / ``status``."
      -}
    • removedInput schema / properties / queue
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Queue key to count issues in."
      -}
    • removedInput schema / properties / status
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Status key to count issues in."
      -}
    • addedInput schema / required
      Added value: +[
      +  "body"
      +]
  2. First observedv0.67.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety and repeat-safety profile is covered. The description adds one genuinely useful behavioral fact — an empty body counts every issue the caller can see, i.e. results are permission-scoped — but says nothing about the return shape or any limits.

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?

Two tight sentences plus one example, front-loaded with the core purpose and the empty-body edge case. Every clause adds information and nothing is 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?

For a single-parameter count endpoint with full schema coverage and read-only annotations, the description covers the purpose, both body fields, and the empty-body case. The only minor gap is no explicit mention that the result is a scalar count, though that is largely self-evident from the name.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by naming the query language (TQL), clarifying that filter is a field → value object, and providing a concrete example body. This makes the single nested body parameter easier to populate correctly.

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 description states a specific verb (count) and resource (issues) with the matching scope (query-language string or filter), so the agent immediately knows this returns a number rather than records. It does not explicitly contrast itself with siblings like tracker_issues_list or tracker_issues_search, which is what would push it to a 5.

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?

Usage is implied rather than stated: the agent can infer this is the tool to reach for when only a total is needed and that an empty body counts everything visible. There is no explicit when-to-use versus tracker_issues_list/search or any exclusion guidance.

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

Deploy Server

Other Tools