gitea-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is potential confusion between list_issues and list_pull_requests due to Gitea's inclusion of PRs in issue listings. The descriptions warn about this, mitigating ambiguity but not eliminating it entirely.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern in snake_case (e.g., list_issues, create_issue). Minor deviations include is_pull_merged and gitea_status, which break the pattern but are still readable.
Tool Count3/5
56 tools is high for a typical MCP server, covering many Gitea features. While the count reflects the platform's breadth, it exceeds the ideal range (3-15) and may overwhelm agents.
Completeness3/5
The tool set covers issues, PRs, actions, releases, and wiki well, but notable gaps exist: no tools for file management (create/update/delete files), branch operations, or pull request reviews. These are significant for a full Gitea integration.
Average 4.5/5 across 56 of 56 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 62 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it explains the direction of the block relationship, the effect on `dep_index`, the same-repo defaults, and the cross-repo configuration requirement. It stops short of noting idempotency, authentication, or error cases, but the core side effects are clearly 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 short and front-loaded with the primary purpose, then moves through role definition, defaults/prerequisites, and return value. Each sentence contributes distinct information, with no filler or redundant prose.
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 six-parameter mutation tool with no output schema, the description covers the essential selection and invocation details: direction, defaults, the cross-repo prerequisite, and the return value. It could add a note about duplicate blocks or comparative guidance with sibling tools, but the core usage is well covered.
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 coverage is 100%, so the baseline is 3; the prose mostly restates or reinforces what the schema already says about `index`, `dep_index`, `dep_repo`, and `dep_owner`. It adds a concise overview of the relationship but no genuinely new per-parameter meaning.
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 leads with "Make an issue block another issue," clearly stating the operation, resource, and relationship. It then defines the blocking direction (`index` is the blocker; `dep_index` becomes blocked) and notes the return value, which distinguishes it from sibling dependency/block tools.
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 supplies useful usage context—default repository/owner behavior and the `AllowCrossRepositoryDependencies` prerequisite—but does not explicitly say when to choose this over alternatives such as `add_issue_dependency`, `remove_issue_block`, or `check_issue_blocked`. The intended use is implied by the description rather than contrasted with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the return value ('Returns the target issue'), the cross-repo configuration requirement (AllowCrossRepositoryDependencies), and defaulting behavior for `dep_owner`/`dep_repo`. It does not cover failure modes like duplicate dependencies or permission requirements, but covers key behaviors well.
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?
Three sentences, each serving a distinct purpose: the action statement, parameter-direction clarification, and cross-repo/return behavior. There is no filler, and the description is front-loaded with the core purpose.
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 6-parameter mutation tool with no output schema, the description covers purpose, direction, defaults, cross-repo constraints, and return value. It omits error scenarios, but these are not essential for selection. The schema handles parameter details, so this is sufficiently complete.
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 100%, so the baseline is 3. The tool description restates the roles of `index` and `dep_index` and the defaulting for `dep_owner`/`dep_repo`, but adds no new information beyond the schema. It does not compensate for any gaps in parameter understanding.
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 opens with 'Make an issue depend on (be blocked by) another issue,' providing a specific verb+resource statement. It clearly distinguishes direction by stating that `index` is the issue gaining the dependency and `dep_index` is the blocker, differentiating from sibling tools like `add_issue_block` that might represent the reverse relationship.
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?
The description implies when to use it by defining the dependency semantics, but it does not provide explicit alternatives or exclusions. It does not compare to `add_issue_block`, `remove_issue_dependency`, or `list_issue_dependencies`, leaving selection context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that new milestones start in state 'open' and returns the milestone with its id. However, it omits details about error handling, idempotency, or required permissions, which are important for a mutation tool.
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 two sentences, front-loading the purpose and then providing key details. Every sentence adds value without redundancy or fluff.
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 no output schema, the description specifies the return value (milestone with id). It covers initial state and parameter requirements. Minor gaps: no mention of error conditions or default behavior for owner/repo, but overall sufficient for a simple create operation.
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%, but the description adds value by noting that `title` is required, `due_on` has an ISO 8601 example, and providing the initial state 'open' which is not in the schema. This helps the agent understand parameter usage beyond the schema.
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 the action 'Create a milestone', identifies the resource, and specifies required vs optional parameters. It distinguishes itself from sibling tools like list_milestones, update_milestone, and delete_milestone by focusing on creation.
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?
The description implies usage when a milestone needs to be created but does not explicitly state when to use or avoid this tool. There is no mention of alternatives or prerequisites, though the defaulting of repo and owner provides some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains pagination (page 1-based, limit <=100) and output fields, but does not cover error cases, authentication, or side effects. Adequate but not thorough.
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 sentences, no filler, front-loaded with the action and key detail (by its index). Every word earns its place.
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?
No output schema, but description defines output fields (sha, html_url, message, optional author) and pagination. It does not mention sorting or missing data, but for a list tool it is reasonably complete.
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 coverage is 100%, so baseline is 3. The description mentions 'index' but adds no new semantic meaning beyond the schema descriptions. Pagination details are already in the schema constraints.
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 it lists commits in a single pull request by its index, which distinguishes it from sibling tools like list_pull_requests (list PRs) and get_pull_request (get PR details). The verb 'list' and resource 'commits in one pull request' are specific.
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 clear context for use: 'Useful for reviewing what a PR changes before merging.' It does not explicitly exclude alternatives, but the context is sufficient for an agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 details key behaviors: required tag_name, auto-creation of tag if missing, defaults for target_commitish, optional booleans, and return value including id. It lacks explicit permissions or rate limit info but covers core behavior well.
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 a single, well-structured paragraph listing parameters in order of importance with no wasted words. Each sentence adds necessary information.
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?
With 8 parameters and no output schema, the description covers most but misses repo and owner parameters, which are only described in the schema. It does mention defaults for target_commitish but not for repo/owner. The return value is partially described (numeric id), but overall completeness is adequate with a notable gap.
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%, baseline 3. The description adds value by clarifying tag_name with an example, explaining name as human-readable, body as Markdown, target_commitish default, and draft/prerelease as optional booleans. It also mentions the returned id, enhancing understanding beyond schema labels.
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 starts with 'Create a release,' clearly stating the verb and resource. It distinguishes from sibling release tools (list, get, update, delete) by specifying creation behavior.
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?
The description is clear that the tool is for creating releases but does not explicitly state when to use it versus alternatives. No when-not or context exclusions are mentioned, though the name and siblings imply straightforward usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it always reports not-found (404 semantics), makes no HTTP request, and has a stable contract. It also explains the reason (missing upstream API) and the future plan, leaving no ambiguity about what happens when invoked.
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 concise and front-loaded with the core action, followed by essential behavioral caveats. Each sentence contributes necessary information (purpose, placeholder semantics, no HTTP request, stability rationale), with no wasted words.
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 tool's simplicity and placeholder nature, the description covers the essential context: what it does, why it reports not-found, and that it is safe to call. It lacks an explicit mention of the response format beyond 'HTTP 404 semantics', but that is sufficient for a tool that always returns not-found. It is complete for current use.
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 coverage is 100%, so the baseline is 3. The description mentions the `id` parameter but does not add meaning beyond the schema descriptions, which already explain the placeholder behavior for each parameter. No additional semantic value is provided.
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 ('Fetch') and resource ('one repository project board (kanban) by id'), clearly distinguishing it from list_projects. However, it does not explicitly contrast with any sibling tool beyond the inherent get-by-id vs list distinction.
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?
It provides clear context about when to use this tool: it is a stable placeholder that always reports not-found, so workflows can attempt a lookup without breaking. It does not explicitly mention alternatives, but the placeholder nature and stability rationale serve as usable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, the description bears full responsibility for behavioral disclosure. It clearly states idempotency ('No error if the topic is not currently on the repo') and topic naming constraints. However, it omits authorization requirements and response format.
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?
Three sentences, each adding distinct value: purpose, idempotency detail, and usage guidelines. No redundancy or unnecessary fluff.
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 removal tool, the description covers the core operation and idempotency. However, it lacks mention of output/return value or required permissions, which would improve completeness given the absence of output schema and annotations.
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 coverage is 100%, so the baseline is 3. The description repeats the topic pattern already in the schema but adds no new parameter-level insights; 'Confirm with the user first' is a usage directive, not parameter semantics.
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 the action: 'Remove ONE topic from a repository by name.' This specifies the exact resource and scope, distinguishing it from sibling tools like add_topic and replace_topics.
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 instructs 'Confirm with the user first,' providing a clear usage guideline. It also implies single-topic removal (via 'ONE'), but does not explicitly contrast with alternative tools like replace_topics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return behavior (returns comment with `id`) and that `body` supports Markdown. Does not mention auth requirements, rate limits, or side effects beyond creation. Adequate but not comprehensive.
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 sentences: first covers action and key parameters, second explains return value and follow-up. No fluff, front-loaded with most important info.
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?
No output schema, but description explains return value (comment with `id`). Covers required parameters and defaults. Does not mention error cases or issue existence requirement, but provides enough for typical use.
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%, but description adds meaning: clarifies `index` as issue number, emphasizes `body` is required and supports Markdown, and hints at default values for `repo` and `owner`. Schema for `body` just says 'Comment body', so Markdown detail is extra value.
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?
Clearly states the action: 'Add a comment to an issue by its `index`.' Specifies resource (comment to an issue) and key parameters (`index`, `body`). Distinguishes from siblings by advising to retain the `id` for later `update_comment`/`delete_comment`.
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?
Describes when to use the tool (add a comment), notes that `body` is required and supports Markdown, and provides follow-up guidance (retain `id` for updates/deletes). Lacks explicit when-not-to-use or warnings about prerequisites, but sibling differentiation is hinted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It discloses that title is required, labels are IDs, and that the created issue is returned with its number. However, it lacks details on permissions, side effects, or error handling.
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?
Three sentences, front-loaded with the main action. Every sentence adds value without redundancy. Highly concise.
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?
No output schema, but description mentions return includes number. With 8 parameters and 1 required, it covers key fields (title, labels, assignees). Omits explanation of optional fields like body, repo, owner, milestone, but schema already covers them.
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%, baseline 3. Description adds value by clarifying that labels are numeric IDs and advising to call list_labels first, and that assignees is an array of usernames. This goes beyond schema 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?
Description clearly states 'Create an issue' with a specific verb and resource. It distinguishes from sibling tools like update_issue or delete_issue by focusing on creation.
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?
Provides guidance on using list_labels to map label names to IDs, and mentions add_issue_labels as an alternative for adding labels by name. Does not explicitly state when not to use this tool, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns the full PR with specific fields, implying a read operation. However, it does not mention permissions, rate limits, or error conditions. For a simple fetch tool, this is adequate but not exhaustive.
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 two sentences, no wasted words. The most critical information (verb, resource, key parameter distinction) appears at the start. Every sentence contributes to understanding the tool's purpose and output.
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 simple fetch tool with no output schema, the description covers the key return fields and parameter usage. Without annotations, it could mention the read-only nature or authentication requirements, but the essential information is present. The tool is fully understandable as documented.
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?
The description adds meaningful context to the `index` parameter by clarifying it is the number shown in the PR URL, not the internal `id`. Input schema coverage is 100%, so the baseline is 3; the description adds value beyond the schema. The `repo` and `owner` parameters are not elaborated, but default behaviors are implied.
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 uses a specific verb ('Fetch') and resource ('one pull request'), clearly identifying the tool's action. It distinguishes the 'index' from the internal 'id', making the purpose unambiguous. The list of returned fields (base/head branches, mergeable status, etc.) further clarifies the scope.
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 explicitly states when to use the tool: 'Fetch one pull request by its `index`', and clarifies what not to use (internal `id`). It does not explicitly contrast with sibling tools like list_pull_requests, but the context of fetching a single item is clear. A slight improvement would be to mention using list_pull_requests for multiple PRs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behavior: returns only the default first page, may truncate long threads, returns oldest-first, and describes the comment structure (id, body, user, timestamps). It explicitly warns against assuming a short list means few comments.
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 very concise: two sentences plus a brief note. It is front-loaded with the purpose and each sentence adds value (purpose, risk, ordering, comment fields). No unnecessary words.
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 no output schema, the description explains what each comment contains (id, body, user, timestamps) and addresses truncation risk and ordering. It is fairly complete for a list tool. Missing mention of filtering or sorting, but none exist in the schema.
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 coverage is 100% so the schema already describes the parameters. The description mentions `index` as the issue number and notes `repo` and `owner` have defaults, but adds minimal extra meaning beyond the schema.
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 it lists comments on one issue by its `index`. The verb 'list' and resource 'comments on one issue' are specific. It distinguishes from sibling tools like create_comment, update_comment, and delete_comment by focusing on listing.
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?
The description implies usage for quick retrieval but warns of truncation. It does not explicitly state when to use this tool vs alternatives (e.g., for full threads, use a different tool with pagination). No when-not or alternative tool is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions pagination (page 1-based, limit ≤ 100) and that each repo object is large, but does not disclose authentication or rate limit details. For a read-only operation, this is adequate but not exhaustive.
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?
Three concise, front-loaded sentences with no waste. First sentence states core function, second gives pagination details, third gives usage guidance. Highly efficient.
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 no output schema, the description adequately describes the tool's purpose, behavior, and usage. It is sufficient for an AI agent to select this tool over siblings for repository discovery. Missing explicit return structure but acceptable.
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 covers 100% of parameters. The description adds value by explaining pagination semantics and advising on keeping limit modest due to large objects. This goes beyond the schema's basic type and range 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 'List repositories the authenticated token's user can access (across ALL owners/orgs).' It specifies the verb (list), resource (repositories), and scope, distinguishing it from sibling tools that focus on issues, pull requests, etc.
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?
It explicitly says 'Use to DISCOVER owner/repo values or find where to work, not to list one repo's issues.' This tells when to use and when not to, effectively differentiating from issue-related tools. However, it does not name a specific alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles behavioral disclosure. It describes pagination ('Paginated (page 1-based, limit <= 100)') and lists the fields in each entry, setting clear expectations for output. No mention of errors or edge cases, but for a read-only list tool, this is adequate.
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?
Three sentences, all essential. No waste, front-loaded with purpose, followed by pagination info, output fields, and usage guidance. Efficient structure.
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?
No output schema, so description carries responsibility for explaining return values. It lists all relevant fields (`filename`, `status`, `additions`, etc.) and explains pagination. Does not cover possible empty results or error cases, but sufficient for typical use.
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 coverage is 100%, so baseline is 3. The description mentions `index` in context and pagination parameters, but adds no new details beyond what the schema provides (e.g., defaults for repo and owner are already in schema). Marginal added value.
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?
Specifically states 'List the files changed in one pull request by its `index`', clearly identifying the verb and resource. Differentiates from siblings like list_pull_commits and get_pull_request by focusing on file changes.
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?
Explicitly says 'Use to understand a PR's diff scope before reviewing or merging', providing clear usage context. Does not explicitly state when not to use or list alternatives, but the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context by stating the return value (the blocker issue) and a common error condition (404 if dependencies are not enabled). It also mentions default behaviors for dep_owner/dep_repo, though not perfectly accurately.
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 three sentences long, front-loaded with the core operation, and each sentence provides distinct, non-redundant information: the action, default behavior, return value, and error condition. There is no fluff.
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 simple remove operation with no output schema, the description covers the essential aspects: purpose, parameter defaults, response, and a key failure mode. It is sufficiently complete for an agent to select and invoke the tool correctly, though a more precise statement about dep_owner/dep_repo defaults would improve it.
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 coverage is 100%, so the schema already documents all parameters. The description adds a brief explanation of the relationship between `index` and `dep_index`, but it largely restates defaults already in the schema and even slightly misstates them ('same repo' vs separate owner/repo defaults). Thus, it adds little value beyond what the schema provides.
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 identifies the action ('Remove a block') and specifies the exact relationship between `index` and `dep_index`. It distinguishes this tool from sibling tools like remove_issue_dependency by focusing on the 'blocks' relationship rather than the inverse dependency relationship.
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 gives clear context for when to use the tool (to unblock an issue), but it does not explicitly mention alternatives or when not to use it. Sibling tools such as remove_issue_dependency are not referenced, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool removes exactly one label (a destructive operation) and errors if the label is not present. However, it does not mention permissions, side effects, or return value. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no unnecessary words. Every sentence adds critical information: what the tool does, what parameter to use, how to get the correct value, and an error condition. Extremely efficient.
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 simple removal tool with no output schema and all parameters described, the description covers the essential behavioral aspects: the action, the required parameter format, and an error case. It does not need to explain return values. Complete for the complexity level.
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 description coverage is 100%, so baseline is 3. The description adds significant value by clarifying that 'id' is the label ID (not name) and pointing to list_labels as the source. It also explains the defaults for 'repo' and 'owner', which are not detailed in the schema.
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 'Remove ONE label from an issue,' specifying the verb (remove) and resource (label from an issue). It distinguishes itself from sibling tools like add_issue_labels, replace_issue_labels, and clear_issue_labels by emphasizing that it removes exactly one label.
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 explicit guidance on the parameter 'id': it must be the label ID (number), not the name, and that the ID can be obtained from list_labels. It also notes an error condition if the label is not on the issue. While it doesn't explicitly compare to alternatives, the context of sibling tools and the 'ONE label' phrasing imply when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains PATCH semantics and color format, but does not disclose error handling, idempotency, or authentication requirements. No annotations to compensate.
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 sentences, front-loaded with essential information, no wasted words.
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?
Covers usage, parameters, and behavior for a 6-parameter tool with no output schema. Missing details on return value and error conditions, but adequate given complexity.
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 covers all 6 parameters (100% coverage). Description adds clarification on id being a number, color being hex, and PATCH semantics, providing extra meaning beyond schema.
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?
Describes updating a label by ID with PATCH semantics, clearly distinguishing from sibling tools like create_label and delete_label.
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?
States to provide any of name/color/description and to get the ID from list_labels, giving clear when-to-use guidance. Does not explicitly mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses the return structure (blocked, blockers, total_dependencies, open_blockers), the pagination behavior, and the 404 error condition for repos lacking issue dependencies. This goes well beyond the schema.
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 concise, well-structured, and front-loaded with the core purpose. Each sentence adds meaningful detail about return values, relationship to sibling tools, and error conditions, with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema or annotations, the description fully compensates by explaining the return fields, the internal pagination, and the specific 404 case. It leaves no critical gaps for an agent to invoke the tool correctly.
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?
The input schema already provides descriptions for all three parameters (100% coverage). The description adds no additional parameter-level context beyond what's in the schema, so the baseline 3 is appropriate.
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 the tool's function with a specific verb ('Check whether an issue is blocked') and defines the blocking condition. It also distinguishes itself from sibling tools by identifying as a convenience aggregator over `list_issue_dependencies`.
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?
It explicitly frames the tool as a convenience aggregator over `list_issue_dependencies` and highlights internal pagination as a differentiator. However, it doesn't provide an explicit 'when to use vs. alternatives' statement beyond the relationship to list_issue_dependencies, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 constraint of unique name and the conflict error, and states the return value includes the label's id. No mention of permissions or side effects, but the behavior is adequately transparent for a create operation.
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?
Three sentences efficiently convey essential information without wasted words. It is front-loaded with the core action and structured logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with 5 parameters and no output schema, the description covers the uniqueness constraint, color format, optional description, and return value. It is complete enough for accurate invocation.
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%, but the description adds value by clarifying the uniqueness requirement for name and the hex format for color (including optional '#' prefix), which goes beyond the schema's pattern description.
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 'Create a label' and specifies required fields. It distinguishes from sibling tools like list_labels, update_label, delete_label by focusing on creation.
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?
The description explains uniqueness and color format but does not explicitly guide when to use this tool over alternatives like update_label. Usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the destructive nature of the operation ('Destructive for that issue's labels'). With no annotations provided, this adequately informs the agent about the mutation effect, though it could mention what happens to the labels (e.g., deletion vs clearing).
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 sentences, front-loaded with the core action and resource, followed by critical usage guidelines. No unnecessary words.
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?
Covers purpose, usage, parameter role, and behavioral trait (destructive). Lacks mention of return value or post-condition, but for a simple removal tool this is mostly complete.
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?
The input schema already describes all three parameters with 100% coverage. The description only reinforces that the `index` parameter identifies the issue, adding no new semantic meaning beyond the schema.
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 the action ('Remove ALL labels from an issue by its `index`'), identifies the specific resource, and distinguishes from sibling tools like 'remove_issue_label' and 'replace_issue_labels'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Remove ALL labels'), what to do first ('Confirm with the user'), and when to use an alternative ('if a known subset must remain, use replace_issue_labels').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses the pagination protocol (page start, limit cap, termination condition) and the directional relationship to list_issue_dependencies. However, it does not explicitly state read-only behavior (though 'List' implies it) or mention ordering/return format, leaving minor gaps.
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 two sentences, front-loaded with the primary purpose, then pagination, then sibling comparison. Every sentence adds value without redundancy or fluff. Excellent structure.
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 list tool with no output schema, the description provides essential operational details: pagination flow and directionality relative to a sibling tool. It lacks explicit mention of response format, but that is not critical given the simplicity. Overall, the description is sufficiently complete for an agent to invoke and use the tool correctly.
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?
The input schema has 100% description coverage for all five parameters, so the schema already documents the parameters well. The description adds minimal extra parameter insight beyond mentioning page and limit in the pagination context. Baseline 3 is appropriate.
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 the tool's function: 'List the issues that are BLOCKED BY this issue' with the phrase 'blocking dependents' adding clarity. It also distinguishes itself from its sibling tool by naming the reverse direction, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: it tells the agent to use this tool for blocked-by relationships and explicitly names the alternative (list_issue_dependencies) for the opposite direction. It also gives concrete pagination instructions (1-based page, limit <= 100, keep paging until fewer than limit), which is highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses pagination (page 1-based, limit <=100) and topic name format constraints. Does not explicitly state it is read-only, but 'list' and 'inspect' imply no destructive behavior. Minor omission of authentication requirements.
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?
Three sentences, no fluff. Purpose is front-loaded, followed by format constraints and pagination details. Every sentence contributes necessary information.
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?
No output schema, but description hints at return value ('topic name list'). Pagination details are sufficient. Could specify the exact structure (e.g., array of strings or object with pagination metadata), but for a simple list tool this is acceptable.
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 covers 100% of parameters with descriptions. Description adds value by explaining pagination behavior and topic name format (lowercase, letters, digits, hyphens), which are not in 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?
Clear verb-resource combination: 'List a repository's topics (tags)'. Explicitly states the output and differentiates from sibling topic editing tools like replace_topics, add_topic, remove_topic by noting it is for inspection before editing.
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?
Explicitly states usefulness for inspection before editing, implying when to use. Sibling differentiation is present via the 'before editing' context. Could explicitly mention not to use for modification, but the read-only nature is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value (the formerly dependent issue), a 404 when dependencies are not enabled, and defaulting of `dep_owner`/`dep_repo`. It doesn't mention permission requirements, but for a simple mutation the key behavioral traits are covered.
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 three sentences, front-loaded with the core action and followed by essential details. It is concise and free of redundancy.
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 absence of an output schema, the description covers the purpose, return value, and a key error condition. With fully described parameters and a clear tool scope, it is sufficiently complete for a moderate-complexity operation.
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. The description adds semantic clarity by explaining the blocking relationship between `index` and `dep_index`, and reinforces the repo/owner defaults. This complements the schema without duplicating it, earning a 4.
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 opens with a specific verb 'Remove' and names the key resources (`index`, `dep_index`), clearly distinguishing it from sibling actions like `add_issue_dependency`. It also explains the dependency direction ('no longer blocked by'), making the tool's purpose unmistakable.
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 implies when to use this tool (to unblock an issue by removing a dependency) and provides defaulting behavior and a 404 error condition. It doesn't explicitly reference alternatives, but the action and sibling context make the usage intent clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that the tool reruns only failed jobs and specifies preconditions. It also advises a best-practice workflow. However, it does not explicitly state whether the operation is idempotent or describe side effects like rate 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?
The description is three sentences, each earning its place: first sentence states the action, second gives the efficiency rationale and precondition, third provides a safety workflow. No wasted words.
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 no output schema, the description could explain the return value, but for a rerun operation the response is typically a status code, which is self-explanatory. The description provides sufficient operational context for correct usage, including prerequisites and verification steps.
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 coverage is 100%, so baseline is 3. The description mentions `runId` in context but does not add new meaning beyond what the schema already provides for the parameters. No parameter-level descriptions are enhanced.
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 the tool's specific purpose: 'Rerun ONLY the failed jobs of an Actions workflow run by `runId`.' It then explicitly distinguishes this from its sibling 'rerun_action_run' by highlighting efficiency when only a subset of jobs failed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: when to use (efficient for failed-only reruns), preconditions (only valid on completed runs, requires Gitea 1.26.0+), and a recommended workflow (call get_action_run first, confirm runId with user). This helps an AI agent avoid errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that `body` is a full replacement Markdown (not a patch) and that authorization is enforced (403). This provides key behavioral traits beyond what the schema alone conveys.
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 concise sentences, each providing essential information without redundancy. The most critical guidance (id source, body behavior, authorization) is front-loaded.
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 4 parameters, no output schema, and a straightforward update action, the description covers the key behavioral expectations. It does not describe the return value, but this is minor for a mutation tool without a specified output schema.
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%, but the description adds crucial context for `id` (clarifying it is not the issue index) and for `body` (full replacement Markdown), enhancing understanding beyond the schema 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 the tool edits a comment, specifies the resource (comment) and action (edit), and distinguishes the `id` parameter from the issue `index`, providing a concrete reference to `list_comments` for obtaining the correct ID.
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 specifies that only the comment author or a repo admin can use this tool else a 403 is returned, providing clear authorization context. It does not explicitly state when to use vs. alternatives, but no sibling tool edits comments, so this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the returned PR includes its 'number', and that prefixing title with WIP prevents accidental merge. This goes beyond a simple creation note.
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?
Three sentences, front-loaded with core purpose, and every sentence adds valuable information without redundancy. It is appropriately sized for the parameter count.
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 10 parameters (3 required) and no output schema, the description covers essential usage: required params, fork handling, labels, and return info. It could mention default repo/owner behavior, but those are environment-specific. Overall, it provides sufficient context for correct invocation.
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 critical nuances: the syntax for cross-fork branches ('owner:branch'), that labels are numeric IDs (schema says 'List of label IDs' but doesn't emphasize they are numbers), and the WIP prefix convention. This significantly enriches the schema.
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 starts with 'Create a pull request.' which is a clear specific verb+resource. It distinguishes itself from siblings like list_pull_requests and merge_pull_request by focusing on creation.
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?
It states required parameters, mentions that for cross-fork PRs use 'owner:branch', advises to call list_labels first for labels, and explains the WIP prefix convention. It doesn't explicitly contrast with siblings but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what is returned and that it's a fetch operation. No annotations, but read-only nature is implied. Could explicitly state no side effects.
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?
Single sentence with precise information about identification and return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose, input, and output for a GET milestone operation. No missing aspects given no output schema.
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?
Adds meaning for id (internal ID) beyond schema. Repo and owner defaults are already in schema. Overall adds value.
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 it fetches a single milestone by internal ID, distinguishes from list_milestones, and lists return fields.
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?
Mentions that id is internal from list_milestones, not title, guiding correct usage. Lacks explicit when-to-use vs alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description clearly indicates a read-only fetch operation with no side effects, and describes return shape.
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 succinct sentences, front-loaded with key purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains the return shape (same as get_release, includes id). Parameters are all described in schema. Complete for a simple fetch tool.
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 coverage is 100%, so baseline is 3. Description adds minimal value beyond schema by reinforcing tag usage and connecting to response.
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 it fetches one release by tag name, provides an example ('v1.2.0'), and distinguishes it from get_release by numeric id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Useful when you only know the Git tag, not the numeric release id', implying when not to use, and notes the response includes id for update/delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses a critical safety behavior ('Secrets are NEVER returned') and enumerates what is reported. It does not mention potential side effects, but as a read-only diagnostic tool, the key behavior is well-covered.
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 two sentences, front-loaded with the main purpose, and every detail serves a purpose. It is concise without sacrificing necessary diagnostic detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains the tool's return content, including fields and security policy, in the absence of an output schema. Given its simple zero-input nature, the description is complete for the agent to understand what to expect.
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?
The tool has zero parameters and the schema coverage is 100% (no properties). The description explicitly states 'Takes no input,' which aligns with the schema. As no parameter explanation is needed, baseline 4 is appropriate.
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 the tool reports resolved connection and credential state, with specific elements listed (baseUrl, credential candidates, session target). It distinguishes itself from sibling CRUD tools by focusing on diagnostics, and explicitly mentions the tool takes no input.
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?
It provides an explicit trigger condition ('Use this when a tool returns 401/403 or NotConfiguredError'), which is clear usage guidance. However, it does not name alternatives or explicitly state when not to use it, though the diagnostic purpose is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return type (boolean) and semantics (merged vs not merged). No side effects mentioned, but as a read-only check, that's acceptable. Could mention error handling for non-existent PRs.
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 sentences, front-loaded with purpose, no wasted words. Efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (boolean check, no output schema needed), the description and schema together provide complete context for correct invocation.
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 covers 100% of parameters with descriptions. Description does not add new parameter info; it reinforces the purpose of the main param (index) indirectly.
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?
Clear verb 'Check whether' + specific resource 'pull request merged'. Distinguishes from sibling tools like merge_pull_request and get_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: call before merge_pull_request to avoid redundant attempt or to confirm final state. No alternatives needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fully and honestly reveals that the tool is a placeholder, always returns an empty list, makes no HTTP request, and that the contract is stable for future changes. It also references the upstream issue. This is exemplary transparency beyond what annotations could provide.
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?
Each sentence earns its place: the first states the purpose, the second explains the placeholder, the third clarifies no HTTP request, and the fourth provides context on stability. It is concise, front-loaded, and contains no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a simple list tool with two optional parameters, no output schema, and no annotations, the description is remarkably complete. It explains the tool's actual behavior (empty list, no request), its practicality (stable contract), and its future direction (transparent change). Nothing crucial is missing for the agent to use it safely.
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?
The schema documents both parameters (repo and owner) with descriptions that include their defaults and the placeholder behavior, achieving 100% schema description coverage. The tool description itself adds no extra parameter-specific meaning beyond the overall purpose, so the baseline score of 3 is appropriate.
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 the tool's function: 'List repository project boards (kanban).' The verb 'list' plus the specific resource 'project boards' with repository scope makes the purpose unambiguous. It also distinguishes itself from sibling tools like 'get_project' (list vs. get) and other list tools (e.g., list_issues) by focusing on project boards.
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 clear context for when to use the tool: 'planning workflows can ask about projects without breaking.' It also explicitly states that the tool 'always returns an empty list' and 'No HTTP request is made,' which implies it should not be used when actual project board data is needed. However, it does not explicitly mention alternative tools or exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses pagination behavior (1-based, keep paging while full page) and return structure. Lacks details on authentication or rate limits, but adequate for a read-only list tool.
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 sentences plus a one-sentence usage guideline. No filler, essential information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, describes return structure, pagination behavior, and parameter context. Covers all necessary aspects for an agent to use correctly.
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%, but description adds practical pagination details for the 'page' parameter beyond the schema's 'Page number'. For pageName, it provides an example confirming schema description.
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 the tool lists revision history of a wiki page by pageName, ordered newest first, with specific return fields. This distinguishes it from sibling tools like list_wiki_pages and get_wiki_page.
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?
Explicitly states use case: 'Use to audit who changed a page and when, before reverting or summarizing changes.' Gives clear context for when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states IRREVERSIBLE, details merge strategies, and mentions failure conditions (SHA guard). Could add more on auth requirements or rate limits, but covers essential destructive behavior.
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 information-dense sentences with no wasted words. Purpose, parameters, and warning are all front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential behavioral aspects, safety warnings, and includes cross-references to sibling tools. No output schema exists, but the description is complete given the tool's complexity.
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 100%, so baseline is 3. Description repeats strategy enum meanings and mentions SHA guard, but does not add significant new info beyond schema.
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 'Merge a pull request by index' with a specific verb and resource. It distinguishes from siblings like get_pull_request and is_pull_merged by explicitly mentioning them in guidelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance: 'IRREVERSIBLE — confirm ... with the user BEFORE merging. Check is_pull_merged first if unsure.' It also mentions alternatives like get_pull_request for checking mergeable status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states PATCH behavior (only provided fields change) and warns about tag_name. Lacks details on permissions or side effects, but sufficient for a patch operation.
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 sentences, front-loaded with core action, then details, then guidance. Every sentence earns its place with no redundancy.
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 9 parameters, no output schema, no annotations, the description covers key behaviors, parameter details, and critical warnings. Lacks description of return value, but that is optional since no output schema.
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 description adds meaning: clarifies that id is numeric and not tag name, notes body supports Markdown, explains tag_name renames the tag. This enriches the schema.
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 it updates a release by numeric id via PATCH, lists editable fields like name, body, draft, prerelease, tag_name, target_commitish. This distinguishes it from sibling tools such as create_release, list_releases, etc.
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 tells users to get the id from list_releases or get_release_by_tag first, and warns about tag_name renaming the Git tag. It does not explicitly state when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Details PATCH behavior (only provided fields change), base64 handling, risk of rename, and return of updated page. Could include error handling or permissions but covers major behaviors.
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?
Five sentences, front-loaded with key info (PATCH, content handling, risk). No wasted words; every sentence adds value.
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?
Covers main aspects for a 6-param tool with no output schema: behavior, risk, and return type. Lacks explanation of error scenarios or owner/repo defaults, but schema descriptions suffice.
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?
Adds significant value beyond 100% schema coverage: explains content as plain Markdown with automatic base64, explicitly states title renames the page, and clarifies pageName as wiki URL form.
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?
Clearly states the tool edits an existing wiki page via PATCH, specifying the resource (wiki page) and verb (edit). Differentiates from siblings like get_wiki_page and create_wiki_page by focusing on editing and advising to read first.
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?
Provides explicit guidance: use to edit a wiki page, with warning about renaming breaking links. Advises to read with get_wiki_page first if uncertain. Lacks explicit when-not-to-use but covers key context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses irreversibility and authorization requirements (403 if not author/admin). It does not mention rate limits or side effects, but for a delete operation the core behavior is well covered.
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 concise sentences, no fluff. Key information (action, resource, prerequisites, warning) is front-loaded and every word serves a purpose.
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 3-parameter delete tool with no output schema, the description is nearly complete. It covers the essential behavioral aspects and usage guidance. A minor gap is no explicit mention of the return value (typically empty), but this is acceptable.
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% with descriptions for all three parameters. The description adds meaning by clarifying that `id` is the comment ID (not issue index) and should come from list_comments. This enhances understanding beyond the schema.
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 it deletes a comment by its `id`, distinguishing it from the issue `index`. It specifies the resource (comment) and the action (delete), and among sibling tools like delete_issue and delete_label, it is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use the `id` from list_comments, warns it is irreversible, instructs to confirm with the user first, and notes that only the author or admin can delete (403 otherwise). This covers when to use, prerequisites, and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It transparently states it returns full release with specific fields, and the verb 'Fetch' implies a read operation. No mention of side effects, but none expected. Could be more explicit about read-only nature, but adequate.
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?
Three sentences, each impactful: first states action and warning, second lists returns, third gives alternative. No wasted words, front-loaded with key information.
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 simple fetch tool with no output schema, description covers the essential behavior, parameters, and alternatives. Lists returned fields. Could mention error handling or prerequisites, but sufficient given low complexity and good schema coverage.
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 100% sets baseline 3. Description adds significant value for the 'id' parameter by explaining it is numeric, not a tag name, and must be obtained from list_releases. This goes beyond schema. Other parameters are briefly noted with defaults, adding limited extra value.
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?
Description clearly states 'Fetch one release by its numeric id' and emphasizes it is NOT the tag name, distinguishing it from sibling get_release_by_tag. It specifies the returned fields, providing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidelines: instructs to get the id from list_releases and use get_release_by_tag when only knowing the tag name. Provides clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully details the return fields (content decoded to Markdown, footer, sidebar, commit_count, last_commit) and handles base64 decoding. Lacks mention of authentication or error handling, but acceptable for a read tool.
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 sentences convey purpose, usage guideline, and return structure with no redundancy. Every sentence adds value.
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 no output schema, the description sufficiently covers return fields and content decoding. It references the sibling tool and explains input defaults, leaving little ambiguity for this simple read operation.
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 baseline is 3. The description adds value by clarifying pageName format with examples and noting default values for repo and owner, exceeding schema info.
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?
Description clearly states the tool fetches a single wiki page by pageName, distinguishing it from list_wiki_pages. It specifies that pageName is the title as in the URL, giving concrete examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use list_wiki_pages first if unsure of the exact page name, providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses pagination behavior, response structure (wrapper object with workflow_runs key), and list of filters. Could mention read-only nature, but it's implied.
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?
Concise: purpose, pagination, filters, response structure, and usage hint in 4 sentences. Front-loaded with key info, no fluff.
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 9 parameters, no required, no output schema, description covers filters and pagination behavior. Response structure is explained. Missing details like error handling or rate limits, but sufficient for basic usage.
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 has 100% coverage; description adds value by explaining pagination logic, filter examples, and response key. This enhances understanding beyond the schema.
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 the tool lists Gitea Actions workflow runs in a repository, specifying the resource and action. It distinguishes itself from siblings like get_action_run, cancel_action_run, and rerun_action_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on pagination (1-based page, limit ≤ 100, stop when fewer than limit), filters (branch, event, status, actor, head_sha), and when to use: find a run's id before using other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains pagination behavior and the 404 error case, which are non-obvious. However, it does not describe the return format (e.g., array of issue objects) or sorting behavior, leaving minor gaps.
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 three concise sentences, front-loaded with the core purpose, then pagination details and alternative reference. Every sentence earns its place with no filler or redundancy.
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 paginated list tool with no output schema, the description covers the essential context: what it returns (blocking issues), pagination mechanics, error behavior, and relationship to a sibling. It could be slightly more explicit about the result shape, but overall it is sufficient for an agent to select and invoke correctly.
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 baseline is 3. The description adds meaning beyond the schema by clarifying pagination semantics (page 1-based, limit max 100, paging strategy) and the dependency-enabled condition. This goes beyond merely restating property names.
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 the tool lists issues that block the given issue, using a specific verb ('List') and resource ('issues that BLOCK this issue'). It explicitly differentiates from the sibling tool list_issue_blocks by naming the reverse direction, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus alternatives: 'Use list_issue_blocks for the reverse direction'. Also gives practical usage instructions for pagination (1-based page, limit <= 100, keep paging until fewer than limit) and notes a specific error condition (404 when dependencies not enabled).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination behavior (1-based page, limit <=100, iterative paging), state default, and the critical detail that Gitea includes pull requests. No annotation provided, so description carries full burden; it covers key behaviors but lacks explicit read-only or auth info.
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?
Concise: 3 sentences plus example. Logically ordered: purpose, pagination, filters, risk/alternative. Every sentence is informative.
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?
Covers pagination, filters, and alternative for pure issues. No output schema, so return format is implied but not explicit. Slightly incomplete, but adequate for a list tool.
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%, baseline 3. Description adds value beyond schema by explaining pagination iteration, the 1-based page, state default, and the risk of pull requests. Example clarifies usage.
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?
Clearly states 'List issues in one Gitea repository' with specific verb and resource. Distinguishes from sibling search_issues by noting the risk of pull request inclusion and suggesting the alternative for pure issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool vs search_issues: 'to list only issues use search_issues with type="issues"'. Also provides an example call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes pagination logic, filter behavior, and default state. No annotations provided, so description carries full burden. Does not mention any side effects or rate limits, but as a read operation it's adequate.
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 sentences and an example, no filler. Front-loaded with main purpose, then pagination and filters. Efficient and clear.
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?
Covers pagination, all filters, and provides example. Does not describe return format, but since no output schema, it is moderately complete for a list operation. Could mention result type briefly.
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%, but description adds value: explains pagination (page/limit usage), labels as comma-separated names, milestone ID, and gives an example. This helps beyond raw schema.
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?
Clearly states 'List pull requests in one Gitea repository.' The verb 'list' and resource 'pull requests' are specific. Distinguishes from siblings like search_issues which is for cross-repo search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit pagination behavior (page 1-based, limit <=100, keep paging until fewer than limit). Gives example usage. Mentions alternative cross-repo search via search_issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states that every existing label is removed and only the listed ones remain, and warns about the destructive nature. Could mention potential errors for non-existent labels, but overall transparent.
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 sentences, front-loaded with the primary action, no wasted words. Every sentence adds value: first declares the purpose, second gives usage warning.
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 parameter count (4), 100% schema coverage, and no output schema, the description is mostly complete. It explains replacement behavior and cautions. Could detail return values or error handling, but reasonable for a replacement tool.
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 baseline 3. The description adds meaning by clarifying that 'labels' is an array of names used for full replacement, and that the operation removes all existing labels. This goes beyond the schema's generic description.
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 uses a strong verb 'REPLACE' and specifies the exact resource 'issue's ENTIRE label set'. It clearly distinguishes itself from sibling tools like add_issue_labels, remove_issue_label, and clear_issue_labels by emphasizing that it replaces all labels at once.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises reading current labels first to preserve any that must survive and to confirm with the user before replacement. This provides clear when-to-use and when-not-to-use guidance, differentiating from partial modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive, all-or-nothing nature, explains that an empty array clears all, and details topic name constraints.
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?
Concise yet comprehensive: every sentence adds value. Key info is front-loaded, no repetition or fluff.
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 tool's simplicity and missing output schema, the description covers inputs, behavior, naming rules, and preread advice. It could mention error handling or response, but is largely complete.
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 baseline is 3. The description adds meaning beyond schema by explaining the REPLACE semantics and the effect of an empty array, adding significant value.
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 it REPLACES the entire topic set, using strong verbs and specifying the resource. It distinguishes from siblings like add_topic and remove_topic by emphasizing the full replacement behavior.
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 advises reading current topics with list_topics first to preserve any, and to confirm with the user. This provides clear context, though it doesn't explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses constraints (only on completed runs, active runs error), behavioral effects (creates new run, increments run_attempt, original unchanged), and version requirement (Gitea 1.26.0+). No annotations exist, so description carries full burden and performs well.
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?
Four sentences, no filler, front-loaded with main action, then constraints, then prerequisites, then alternative. Very efficient.
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?
Covers purpose, usage, constraints, and alternative well. Lacks information about return value (e.g., does it return the new run ID?), but given no output schema, the description is still fairly complete. Minor gap.
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 coverage is 100% and description does not add new parameter semantics beyond mentioning runId in context. Baseline 3 is appropriate.
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?
Description clearly states the tool reruns an entire Actions workflow run by runId, and distinguishes itself from the sibling tool rerun_action_run_failed_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call get_action_run first to confirm run completion and to confirm runId with the user. Also advises when to use rerun_action_run_failed_jobs instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the transparency burden. It discloses that the tool searches across all repositories the token can see, which is a key behavioral trait. However, it does not mention pagination behavior or result ordering, though the schema covers page and limit.
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 three sentences long, each with a distinct purpose: stating the action, providing use cases, and contrasting with a sibling. No extraneous information.
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 tool's complexity (6 parameters, no output schema), the description effectively covers the cross-repo search nature, use cases, and sibling differentiation. It does not mention return format or ordering, but the schema handles pagination.
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?
The input schema has 100% description coverage, so baseline is 3. The description adds value beyond the schema by explaining how to use the 'type' parameter to exclude pull requests, which is not in the schema description.
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 the tool searches issues and pull requests across all repositories using keyword, type, state, and labels. It distinguishes from the sibling tool list_issues by advising to use that for single-repo listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for 'find issues about X' or duplicate detection across repos' and provides the tip to set type='issues' to exclude pull requests. It also tells when not to use it: for listing one repo's issues use list_issues instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that labels are replaced entirely, a key behavioral nuance. States PATCH semantics. No annotations exist, so description carries full burden; it covers the major behavioral traits but omits details like idempotency, permissions, or reponse format.
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?
Extremely concise: one sentence for core action, one for label risk. Every sentence is necessary and front-loaded. No wasted words.
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 10-parameter tool with no output schema, the description covers the most critical behaviors (PATCH, label replacement, state, milestone). It lacks detail on assignee vs assignees and default repo/owner, but these are in schema. Reasonably complete given complexity.
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 baseline is 3. Description adds value beyond schema by explaining label replacement behavior and state enum context. Other parameters are not elaborated, but the added context elevates it.
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?
Clearly states 'Update one issue by `index`' with PATCH semantics, distinguishing from other issue operations like add_issue_labels and remove_issue_label. The verb+resource+key parameter are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (PATCH update) and when-not-to (label change direction to add/remove tools). Also clarifies state values and milestone by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses PATCH semantics, rename effect on URL, and ability to clear description/website with empty string. Could be improved by mentioning required permissions or lack of destructive side effects beyond rename.
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 sentences efficiently convey purpose, PATCH nature, editable fields, and important warnings. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description states 'Returns the updated repository'. Covers all 7 optional parameters with special behaviors (clearing, rename). Completes the context for effective agent use.
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 description adds valuable usage guidance: empty string to clear description/website, branch must exist, rename caution. This significantly aids correct parameter use.
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 the verb 'Edit' and the resource 'ONE repository's metadata', specifies it's a PATCH operation, and distinguishes it from sibling tools like create, delete, list, etc.
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?
Provides clear when-to-use context and lists editable fields. Includes a caution about renaming with 'name'. Does not explicitly mention when not to use or suggest alternatives, but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses additive behavior, deduplication, and error condition. However, it does not mention response format or permissions. Still, it covers key behavioral aspects well.
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?
Three sentences, front-loaded with the action, no filler. Every sentence provides essential information. Extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an additive label operation with 4 parameters and no output schema, the description covers the core behavior, error conditions, and references list_labels for validation. It is complete enough for an agent to use correctly without ambiguity.
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?
Input schema covers 100% of parameters. The description adds value by clarifying that labels are names (not IDs) and that repo/owner have defaults, which the schema only hints at via descriptions. This helps agents use the parameters correctly.
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 it adds labels to an issue by its index, specifying that labels are names, not IDs. This distinguishes it from sibling tools like remove_issue_label, replace_issue_labels, and clear_issue_labels, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: get valid names from list_labels, warns about 404 errors for non-existent names, states additive behavior and duplicate filtering. Implicitly tells when not to use it (e.g., for replacement, use replace_issue_labels).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses partial destructiveness ('active jobs are killed and their partial results are discarded') and states the effect ('conclusion becomes cancelled'). No contradictions.
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?
Concise, front-loaded with main action, followed by conditions, warning, and usage guideline. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately explains what happens (run canceled, conclusion changed), warns about partial destruction, and provides prerequisite call. Complete for its purpose.
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 100%, so baseline is 3. Description mentions runId but does not add significant detail beyond schema for repo and owner defaults. Acceptable but not enhanced.
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?
Clearly states 'Cancel one Actions workflow run by runId', with specific verb and resource. Distinguishes from siblings by describing the scope and conditions (only active runs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (only active runs) and when not to (completed runs return error). Provides prerequisite step: 'ALWAYS call get_action_run first to confirm the run is still active, and confirm the runId with the user before cancelling.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that the deletion is permanent and irreversible, and that it also removes the label from every issue that has it. This is excellent transparency about side effects and destructive nature.
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 sentences: first states purpose and critical warning, second gives usage instruction. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is destructive with no output schema, the description covers the key aspects: what it does, side effects, prerequisite step, and user confirmation requirement. Complete for safe usage.
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?
The description adds meaning beyond the schema by clarifying that the id must be a number (not the name). The schema already covers repo and owner with defaults, but the warning about id type is valuable.
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 the tool's action (permanently delete a label) and the resource (label by id). It distinguishes from siblings like create_label or update_label by emphasizing that it uses numeric id, not name.
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 instructs the user to get the id from list_labels and confirm with the user before deleting. This provides clear when-to-use guidance. However, it does not explicitly mention alternatives like remove_issue_label, but that is a different operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses irreversibility, impact on issues (not deleted, milestone becomes null), and safety guidance (confirm with user). This is comprehensive for a destructive operation.
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 concise with three sentences: action, side effects, and usage guidance. Every sentence adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fully covers the tool's behavior, side effects, and usage. It is complete for a delete tool.
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?
The input schema has 100% coverage, explaining all three parameters (id, repo, owner). The description only references the 'id' parameter, adding no additional meaning beyond the schema. Baseline is 3.
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 'permanently delete a milestone by id', specifying the action and resource. It distinguishes itself from the sibling tool update_milestone by noting that closing is preferable to preserve history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to confirm with the user first and provides an alternative (update_milestone with state closed) to avoid irreversible deletion. Also explains that issues keep existing but lose the milestone assignment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description emphasizes irreversibility, permanence, and tag deletion ambiguity. No annotations provided, so description compensates well.
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?
Concise 3 sentences, every sentence adds essential information: action and input, behavioral warning, usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action, input, irreversibility, side effects (tag deletion), and provides alternative. No output schema needed; context is complete for a delete operation.
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 has 100% coverage with descriptions that include defaults and id clarification. Description does not add new parameter info beyond reinforcing key point, so meets baseline.
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?
Specific verb 'delete' and resource 'release', clarifies input type (numeric id not tag name), distinguishes from sibling tools (update_release with draft, get_release_by_tag).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (confirmed id, irreversible deletion) vs alternative (use update_release with draft to unpublish), and warns about side effects (tag deletion dependent on config).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that deletion is permanent, history only survives in git repository, and emphasizes irreversibility. This is transparent and actionable.
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 sentences, no fluff. Front-loaded with action and key information. Every sentence is necessary and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no output schema, the description sufficiently covers behavior (permanence, recovery via git clone), required confirmation, and alternative tool. It is complete for the agent's decision-making.
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 coverage is 100%, so baseline is 3. The description adds context for pageName (e.g., 'Home', 'Getting-Started') and mentions repo/owner defaults, but these are also in schema descriptions. No significant extra meaning beyond schema.
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 the action (delete a wiki page permanently) and the resource (wiki page by pageName). It distinguishes itself from the sibling update_wiki_page by recommending it as an alternative for blanking or redirecting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides guidance: confirm pageName with user first, prefer update_wiki_page as alternative, and warns about irreversibility. This helps the agent decide when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It states the tool fetches a run and returns specific fields (status, conclusion, etc.), implying read-only behavior. However, it does not explicitly declare 'readOnly' or mention potential side effects, but the context is clear.
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?
Three sentences, front-loaded with purpose, then usage guidance. No unnecessary words; each sentence adds meaningful information.
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?
No output schema, but description lists key return fields. It provides enough context for typical usage (fetching run details, verifying status before other actions). Could be slightly more exhaustive about the return format, but sufficient.
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 description adds value by clarifying that `runId` is numeric and not the workflow name or index, and that `repo` and `owner` default to environment variables. This supplements the schema effectively.
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?
Description clearly states the action: 'Fetch one Actions workflow run by its `runId`'. It specifies the resource and key identifier, distinguishing it from sibling tools like cancel_action_run and rerun_action_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance provided: 'Call this BEFORE cancel_action_run (to verify the run is still active) or rerun_action_run (to verify it has completed and is rerunnable).' This tells the agent when and in what order to use this tool relative to others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description is accurate and clarifies the parameter semantics (index vs id). It does not disclose side effects, but for a read-only operation this is sufficient.
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?
One sentence with a brief clarification, no wasted words. Front-loaded with the core action.
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?
Adequately covers the purpose and parameter meaning for a simple get tool. Mentions what can be read. Could mention response format but not required since no output schema.
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?
Adds significant meaning beyond schema by explaining that index is the number in the URL (e.g., #42) and not the internal id, and by listing what can be read (body, labels, assignee, milestone).
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 the tool fetches one issue by its index, distinguishing it from siblings like list_issues and search_issues. It specifies the resource and key parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('use to read the full body, labels, assignee, or milestone of a single issue') and clarifies the index parameter's meaning, helping the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses default behavior (only open milestones), pagination constraints, and lists returned fields. Could add authentication/rate limits but sufficient.
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?
Four well-organized sentences, front-loaded with purpose, no redundancy. Every sentence adds value.
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?
No output schema, but description lists key milestone fields. Covers pagination and state filter. Slightly missing sorting or ordering, but overall complete for a list tool.
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 100% (baseline 3). Description adds significant value: explains page numbering, limit cap, state default, and specifies output fields. Goes beyond schema definitions.
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?
Clearly states 'List milestones in a repo' — specific verb and resource. Distinguishes from siblings like get_milestone, create_milestone, etc., as a listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions pagination (1-based, limit<=100) and warns about the default state filter showing only open milestones, advising to pass state='all' or 'closed' for full results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses return metadata fields, pagination details (1-based, limit <=100, paging logic), and error condition (404). Also includes an example call. Highly transparent.
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 sentences plus an example. No unnecessary words. Purpose and key details front-loaded. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains what is returned (metadata fields). Covers error case and pagination. Complete for a listing tool.
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%, each parameter described. Description adds context beyond schema: page is 1-based, limit <=100, and pagination logic. Example demonstrates usage. Adds moderate value.
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?
Clearly states it lists all wiki pages in a Gitea repository, specifies metadata fields returned (title, html_url, sub_url, last_commit), and distinguishes from content retrieval. Purpose is specific and actionable.
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?
Provides when-to-use context: listing wiki pages metadata. Includes pagination behavior and precondition (wiki feature enabled). Does not explicitly state when not to use vs siblings like get_wiki_page, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Fully describes behavior: reads upstream first, then origin, then any other remote; returns all discovered remotes; defaults path to current directory; errors if no parseable remote. No annotations exist to supplement, so description covers everything.
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?
Three sentences: action, reading order, usage recommendation, error behavior. All information is front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers detection method, order, default, error case, and usage context. It is complete for the agent to understand when and how to invoke.
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 coverage is 100% and the description adds the note about path defaulting to current directory, which is already in the schema. However, it provides context on how the parameter interacts with the overall behavior (remote detection), so it's adequate but not extra.
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?
Clearly states the action: detect baseUrl/owner/repo from git remotes. The verb 'detect' and the resource (owner/repo from remotes) are specific. It distinguishes itself from siblings as a setup tool for establishing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call once at session start to establish owner/repo instead of guessing. It also describes the fallback order (upstream, origin, any other) and error case, providing clear when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the pagination behavior (1-based pages, limit <= 100, break condition), response fields (id, name, color, description), and the naming/ID inconsistency across mutations. No contradictions.
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?
Extremely concise: two sentences cover purpose, pagination, response shape, and usage advisory. No wasted words.
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 no annotations or output schema, the description covers all key behavioral aspects. It lacks explicit error handling or a note about empty results, but is otherwise complete.
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 has 100% coverage for all 4 parameters, but the description adds important context: pagination strategy (page until fewer than limit) and defaults for owner/repo. This goes beyond the schema's basic 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 the tool lists labels in a repo with specific pagination details. It distinguishes from sibling tools like create_label, update_label, etc., by explicitly calling out that it should be used before mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to always call this before label mutations, explaining that label endpoints mix names and ids. This provides clear when-to-use and why-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: pagination details (1-based, limit <=100, continuation strategy), filter semantics, and the structure of returned releases (fields like id, tag_name, name, body, draft, prerelease, attachments).
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 efficiently written with no wasted words, front-loading the purpose, then logically flowing to pagination, filters, return fields, and an example, all in a single clear paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is remarkably complete: it covers pagination, filters, return field semantics, and even links the id to other tools. It enables an agent to use the tool correctly without ambiguity.
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 significant value by explaining pagination continuation logic, filter usage (draft and prerelease), default values for repo and owner, and an example call, far exceeding the bare schema 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 'List releases in one Gitea repository' with a specific verb and resource, and distinguishes itself from sibling tools like get_release and list_pull_requests by focusing on releases and pagination.
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 explicit pagination strategy ('keep paging until a page returns fewer than limit') and explains optional filters, but does not explicitly mention when not to use this tool or suggest alternatives like get_release for single releases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses idempotent behavior ('adding an existing topic does not error') and format constraints for topic name, which are not fully captured by schema alone (schema has pattern but description explains reasoning).
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 sentences, zero waste. The core action, idempotency, format rule, and usage alternative are front-loaded and efficiently communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low complexity (3 params, 1 required), description covers all necessary context: what it does, side effects, constraints, and relationship to siblings.
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 baseline is 3. Description adds value by explaining idempotency implication for the topic parameter and the practical reason for preferring 'replace_topics' over multiple calls.
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 the verb 'Add' and the resource 'topic to a repository by name'. It distinguishes from siblings like 'replace_topics' and 'remove_topic' by specifying the scope (one topic) and the preferred alternative for multiple topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use this tool vs. alternatives: 'To add several topics at once or to set the exact desired set, prefer replace_topics.' Also mentions idempotency, which informs safe repeated usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses session-scoped, never-persisted behavior, token handling (tokens never pass through), strict username filtering, and re-discovery triggers. This is rich, unambiguous behavioral context beyond anything structured.
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 compact yet information-dense. Every sentence earns its place: first sentence states purpose and scope, second lists accepted parameters and requirement, third explains credential sources and re-discovery, fourth addresses token handling, fifth clarifies filtering and usage triggers. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role (configuration) and absence of output schema/annotations, the description covers all essentials: input parameters, minimal requirement, credential flow, identity selection, and usage scenarios. No critical behavioral gaps remain for an agent to invoke it correctly.
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?
The schema already covers all four parameters at 100%, giving baseline 3. The description adds meaningful semantics: 'at least one is required', base_url/username trigger re-discovery, and username's exact-match filtering. It enriches the static schema descriptions into actionable behavioral rules.
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 uses a specific verb 'Configure' with a clear resource 'Gitea connection' and explicitly states session scoping and non-persistence. It clearly distinguishes this configuration tool from all sibling tools, which perform issue, repo, or release operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'Use this when the server started unconfigured or when you need to switch instances/identities mid-session.' It also explains the re-discovery trigger conditions, giving clear context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavior: required title with special names, base64 encoding handled automatically, optional commit message, failure on duplicate, and return of created page with decoded content.
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?
Four sentences, front-loaded with main action, no unnecessary words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: parameters, behavior, failure risk, and return value. No output schema needed given the description of return content.
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%, but the description adds meaningful context: clarifies title values, that content is plain Markdown and base64 is handled, and that message is optional commit message.
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 the tool creates a wiki page, specifies special titles ('Home', '_Sidebar', '_Footer'), and distinguishes it from sibling tools like list_wiki_pages and update_wiki_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (create new page) and when not to use (if page exists, use list_wiki_pages or get_wiki_page first then update_wiki_page), and explains content format handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: permanent deletion, irreversibility (no recycle bin), potential failure, and the need for user confirmation. This is comprehensive.
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 extremely concise—two sentences with no wasted words. It front-loads the core action and immediately follows with critical warnings and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive operation with no annotations or output schema, the description covers all essential aspects: what it does, how to use it safely, what can go wrong, and when to avoid it. It is complete for effective tool selection.
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?
The schema covers 100% of parameters, so baseline is 3. The description adds semantic guidance by emphasizing that the `index` must be confirmed with the user, which provides practical usage context beyond the schema's type and constraint.
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 the action ('PERMANENTLY delete an issue by `index`'), specifying the resource and how to identify it. It distinguishes from sibling `update_issue` by noting that closing is a preferable alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: confirm the index with the user first, and prefer `update_issue({ state: 'closed' })` instead of deletion. It also notes the operation may fail if the instance disallows deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses PATCH behavior, state transition effects, label replacement risk, and base retargeting irreversibility. No annotations provided, so description carries full burden and meets it.
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 dense, front-loaded sentences with zero waste. Every sentence provides critical guidance.
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?
Covers key behaviors and risks for all 11 parameters, but does not describe return value format. Minor gap given high complexity.
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?
Adds significant context beyond 100% schema coverage: explains labels replacement semantics, state meaning, and base retargeting risk.
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?
Clearly states the tool updates a single pull request by index using PATCH semantics. Distinguishes from sibling merge_pull_request by clarifying state change without merging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use alternatives (add_issue_labels/remove_issue_label) for single label changes, and warns about base retargeting rarely reversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It transparently explains the PATCH behavior, the effect of state changes, and that closing a milestone leaves issues open but ungrouped.
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 well-structured sentences. Front-loaded with main action, followed by concise behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers all essential aspects: what fields change, PATCH behavior, and the nuance about closing milestones. Complete for agent decision-making.
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 description adds meaning by listing updatable fields, explaining the state enum, and noting defaults for repo/owner. Adds value beyond schema.
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?
Clearly states the action 'Update a milestone by id' with PATCH method. Specifies the resource (milestone) and distinguishes from sibling tools like create_milestone, delete_milestone, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on what fields can be provided (title/description/due_on/state) and a critical behavioral note about closing a milestone not closing its issues, helping the agent avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gitea_mcp MCP server](https://glama.ai/mcp/servers/amonstack/gitea_mcp/badges/card.svg)](https://glama.ai/mcp/servers/amonstack/gitea_mcp)

Score Badge

Copy to your README.md:

[![gitea_mcp MCP server](https://glama.ai/mcp/servers/amonstack/gitea_mcp/badges/score.svg)](https://glama.ai/mcp/servers/amonstack/gitea_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/amonstack/gitea_mcp'

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