Skip to main content
Glama

Gitea: List milestones

gitea_list_milestones
Read-only

List milestones in a Gitea repository by site, owner, and repo, with optional state filtering, to track project progress and open or closed milestone status.

Instructions

[UNIFIED] List all milestones in a repository.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>",
      "owner": "<owner>",
      "repo": "<repo>"
    },
    "name": "gitea_list_milestones"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoYes
siteYes
ownerYes
stateNoopen

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0
  2. Removedv3.13.1
  3. First observedv3.4.0

TDQS

C2.9/5.0
Behavior2/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. Beyond that the description adds nothing: it does not say that results default to open milestones only, whether closed milestones require an explicit state value, or anything about pagination or ordering of results.

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?

A single short sentence with the scope front-loaded and no padding. It is efficient, though "[UNIFIED]" is dead weight and the brevity comes at the cost of any useful detail.

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

Completeness3/5

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

For a simple read-only list tool with no output schema, a one-liner is defensible, and the annotations carry the safety profile. However, with four parameters at 0% schema coverage and a non-obvious state default, the definition leaves gaps an agent must guess at.

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 0%, so the description has to compensate. "In a repository" loosely maps to owner/repo, but the site parameter and the state filter (defaulting to "open") are left entirely unexplained, so callers cannot infer how to retrieve closed milestones.

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?

"List all milestones in a repository" gives a specific verb (list) plus resource (milestones) and scope (repository), which is enough to separate it from gitea_create_milestone. The gratuitous "[UNIFIED]" prefix adds no discriminating information, and no sibling alternative (e.g. create_milestone) is named as a contrast.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives or when not to call it. The only usage-relevant hint buried in the schema is the state default, and the description never surfaces it.

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