forgejo-projects-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target a distinct resource and action (projects, columns, issues, milestones), and descriptions clarify boundaries between close/delete, remove/delete, and get/read. A few pairs—get_project vs read_project and add_issues_to_project vs create_issue with project_id—require careful reading but are ultimately distinguishable.
Naming Consistency3/5
The dominant verb_noun pattern is clear (create/delete/list/close/reopen), but the set mixes synonyms: update_project vs edit_column/edit_milestone, get_project vs read_project, list_milestones vs read_milestone, plus the non-standard forgejo_status and authenticate. It remains readable but lacks a single consistent convention.
Tool Count2/5
At 31 tools, the surface is heavy for a Forgejo project-management server; the rubric places 25+ in the too-many range. The count is inflated by bulk variants and several full-content read_* tools that could potentially be consolidated.
Completeness3/5
The surface covers auth, repositories, projects, columns, cards, and milestones with CRUD and lifecycle operations. However, there is no update_issue/edit_issue for title/body/state/assignees/labels after creation, and label and assignee management is absent, leaving a notable workflow gap.
Average 3.4/5 across 31 of 31 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under The Unlicense.
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

Behavior2/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. Saying 'Delete a milestone' does not explain whether deletion is permanent, whether it affects associated issues, or what permissions are required. The destructive nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no wasted words. However, it is under-specified to the point that it provides almost no operational guidance beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is incomplete. It omits behavioral context such as permanence, effects on related data, and any required authorization, which an agent would need to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the three parameters: owner, repo, and milestone_id. It does not clarify which identifier to use, how milestone_id should be obtained, or any relationships among the parameters.
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 uses a specific verb ('delete') and a specific resource ('milestone'), clearly stating what the tool does. It does not explicitly differentiate from sibling tools like edit_milestone or close_milestone, but the action 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, side effects, or situations where another sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 names the action but doesn't disclose side effects, permissions required, reversibility, or what happens if the milestone isn't closed. The single sentence is minimally informative and leaves the agent guessing about the operation's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It's appropriately short for such a focused operation, though the brevity comes at the cost of behavioral and parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters, no output schema, and no annotations, yet the description provides no usage context, no parameter hints, no return-value info, and no behavioral detail. It's the minimum viable statement of what the tool does, but an agent has almost nothing to go on for correct invocation beyond the parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds nothing about the three required parameters (owner, repo, milestone_id). An agent must infer that owner/repo identify the repository and milestone_id identifies the target milestone, which is guessable but not documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Reopen a closed milestone'), making the core action clear. However, it doesn't differentiate this tool from sibling tools like list_milestones or forgejo_status, which also operate on milestones/repositories, so the agent must infer the distinction from the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use reopen_milestone versus alternatives. The description doesn't mention prerequisites (e.g., milestone must exist and be closed), error conditions, or any context that would help an agent decide this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. 'Close' implies a state change, but the description does not disclose whether the operation is reversible, whether it sets a 'closed' state vs removes the milestone, whether it requires an existing milestone, or what the side effects are. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and easy to parse, though it is so brief that it borderlines on under-specification rather than true conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only three scalar parameters and no output schema, so the complexity is low. However, the complete lack of annotations, behavioral disclosure, and parameter semantics leaves an agent without enough context to confidently invoke it correctly, particularly around the close-vs-delete ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning. The parameters owner, repo, and milestone_id are self-explanatory from their names and types, but the description does not clarify the relationship between them (e.g., that milestone_id belongs to the identified repository) or any constraints such as the milestone needing to be open.
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 and resource: 'Close a milestone.' This is clear and unambiguous about the operation being performed. However, it does not differentiate itself from sibling tools like list_milestones, relying on the verb to imply the distinction rather than stating it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of when not to use it. Notably, there is no clarification about how closing relates to deleting or completing a milestone, which is a key usage distinction an agent would need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It says 'Close (archive)' which implies the project is archived rather than deleted, but it does not state whether the action is reversible, what happens to associated cards/issues, whether it requires special permissions, or what the response will be.
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, front-loaded sentence with no filler or redundant phrasing. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is too thin. It does not explain prerequisites, reversibility, side effects, or return behavior, leaving an agent to infer important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters owner, repo, or project_id. The parameter names are fairly self-explanatory, but the description adds no meaning beyond what the raw schema already exposes.
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 uses a specific verb ('Close') and resource ('a project'), with the parenthetical '(archive)' clarifying the intended meaning. It is clearly distinguishable from sibling operations like delete_project, update_project, and reopen_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as update_project, delete_project, or reopen_project. The description implies the operation archives/closes a project but provides no conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It does not mention required permissions, side effects, whether the column is appended in a particular position, or what the response contains. The only behavioral detail added is that color is optional and provided as a hex value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. The Args section is compact and adds value for the color parameter. However, the brevity contributes to under-specification of the other required parameters, so it is not fully appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, four of them required, no annotations, no output schema, and many sibling tools, this description is too sparse. It covers only color and gives no explanation of the GitHub context (owner/repo), project identification, or column naming. An agent selecting and invoking this tool would need to infer critical details from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by documenting parameters. It does document the color parameter with a format example, but it does not explain the required parameters: owner, repo, project_id, and title. The agent is left without guidance on what owner/repo/project_id refer to or what the title should represent.
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 clear action and target: 'Add a column to a project board.' This distinguishes it from sibling tools like edit_column or delete_column, though it does not explicitly contrast itself with them. The resource and verb are specific enough for an agent to understand the primary operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as edit_column, delete_column, or set_default_column. The description only states what it does, leaving the agent to infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states the fact of creation without addressing side effects, authorization needs, idempotency, response behavior, or error conditions. The deadline format note is parameter-level detail, not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core action in the first sentence. The extra argument note is minimal and not redundant, keeping the description free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a create operation with no annotations, no output schema, and five parameters, the description is too sparse. It omits the required repository context, expected return value, and any prerequisites, making it incomplete for an agent to invoke correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds only the 'YYYY-MM-DD' format for the deadline parameter, leaving the other four parameters (owner, repo, title, description) without any additional meaning beyond their schema titles and types. Given that the description covers only 1 of 5 parameters, it does not compensate for the lack of rich schema descriptions.
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 'Create a milestone' uses a specific verb and resource, clearly distinguishing it from sibling tools like edit_milestone, close_milestone, and delete_milestone. It does not explicitly mention the repository context, but the required owner/repo parameters in the schema make the scope evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of conditions, prerequisites, or situations where a different milestone tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the core state change (closed to open) but says nothing about authentication requirements, side effects, error behavior when the project is already open, idempotency, or the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single efficient sentence with no filler or repetition. It is front-loaded and easy to parse, though it sacrifices detail that other dimensions require.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 3 undocumented required parameters, a five-word description is insufficient. An agent cannot confidently determine parameter semantics, success/error behavior, or how this tool fits among the sibling project-management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for owner, repo, or project_id beyond their names. The names are conventional, but there is no disambiguation of what project_id refers to (e.g., a repo project vs. a milestone) or any format constraints, so the description fails to compensate for the schema gap.
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 gives a specific verb (reopen) and resource (project), and adds the precondition 'closed', which helps distinguish it from siblings like close_project and archive_project. However, it is close to a restatement of the name with only a marginal addition, so it falls just short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The word 'closed' implies a precondition, but the description does not name sibling tools, exclusions, or conditions that would help an agent choose between reopen_project, close_project, and archive_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the destructive nature ('Permanently delete') but does not disclose consequences like irreversibility, potential impacts on related data, or authorization requirements. The term 'permanently' hints at irreversibility, adding some value, but the description is otherwise minimal.
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, concise sentence that directly states the action and key parameter relevance. There is no unnecessary information, and it is appropriately front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity is low (3 parameters, no output schema), the description covers the basic purpose but omits important context like the need for authorization, the permanent nature of the action, and any prerequisites. For a destructive operation, more context is needed to guide safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameters. It mentions 'by number' which clarifies the 'number' parameter's role, but it does not explain the meaning of 'owner' and 'repo' beyond their names. The schema provides their types, and the description adds only a slight clarification for 'number'.
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 clearly states the verb 'delete' and the resource 'issue by number', which is specific and unambiguous. It distinguishes itself from siblings like list_milestones or create_project, though it does not explicitly name any siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as permissions required to delete an issue, or any conditions under which deletion should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full behavioral burden. It states the core mutation and the ordering behavior, but it does not disclose what happens to existing card positions, whether the operation is idempotent, permission requirements, or the response 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?
The description is a single front-loaded sentence with no filler or repetition. Every phrase contributes to the core semantics, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-required-parameter mutation with no annotations, no output schema, and a near-identical sibling (bulk_move_cards), the description is too thin. It omits usage guidance, side-effect details, and how this tool differs from related operations.
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?
With 0% schema coverage, the description must compensate. It usefully clarifies that issue_numbers are GitHub issue numbers and that column_id is the destination column, but it does not clarify the role of project_id or the owner/repo relationship beyond their parameter names.
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 clear action on a specific resource: move one or more issues (cards) into a column, with ordering. However, it does not explicitly differentiate from the sibling bulk_move_cards, which appears to cover the same multi-card operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use move_card versus alternatives such as bulk_move_cards or add_issues_to_project. The description implies a column-targeting move, but an agent cannot tell which sibling is appropriate without additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It reveals the mutation nature implicitly but says nothing about authentication requirements, whether null values clear a field versus leave it unchanged, partial-update semantics, or what is returned after the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words: verb, resource, and field list are all present up front. The only deduction is the misleading 'description' field name, which is an accuracy issue rather than a structure problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too thin. It omits return-value expectations, null-clearing semantics, and auth context, and it introduces a phantom field, leaving gaps an agent must resolve by inference across the sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With roughly 40% schema description coverage (only title and card_type are named; owner, repo, and project_id are not), the description needed to compensate more than it does. It also introduces a 'description' parameter that is absent from the schema and fails to clarify that both title and card_type default to null, leaving an agent unsure whether null means 'skip' or 'clear'.
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 and resource — 'Update a project's title, description and/or card type' — which clearly distinguishes it from lifecycle siblings like create_project, close_project, reopen_project, and delete_project. However, it names a 'description' field that does not exist in the input schema, which slightly muddies what an agent can actually pass.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the tool name plus the project resource in the description suggest using this for modifying project metadata rather than for lifecycle operations or for editing columns/milestones/issues. There is no explicit when-to-use guidance, no exclusions, and no routing toward alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 core write action ('add issues as cards') but does not explain idempotency, permissions, failure behavior when an issue number is invalid, or whether this is copy vs move.
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, front-loaded sentence with no redundant words. Every element earns its place.
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 4-parameter mutation with no output schema, this is mostly adequate; it tells the agent the inputs and intended effect. It still omits error conditions, return behavior, and prerequisites, so it is not fully 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 0%, but the description clarifies that issue_numbers are repo-scoped issue numbers and that the operation targets a project. Owner and project_id remain underspecified, though their names are self-explanatory.
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 names a specific operation — adding existing issues to a project as cards — and clarifies that issue numbers are repository-scoped. This clearly differentiates it from create_issue and remove_issues_from_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided: it doesn't say when to choose this over move_card, create_issue, or remove_issues_from_project, nor does it state prerequisites such as the issues or project needing to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It says title and/or color can be edited, but does not explain whether omitted fields are left unchanged, whether null values clear them, any permission requirements, or what the response contains. The mutation is implied but not detailed.
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?
A single, front-loaded sentence states the verb, resource, and editable fields with no wasted words. Given the simplicity of the operation, the length is appropriate.
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 six parameters, no output schema, and no annotations, the description is a minimal viable definition. The schema covers required identifiers, and the description identifies the editable fields, but an agent would benefit from explicit notes on optionality, null semantics, and response behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that title and color are the editable values, which maps to those parameters, but it adds no meaning for the identifier parameters (owner, repo, project_id, column_id) or accepted formats for title/color. The names in the schema are self-explanatory, so this is minimally adequate.
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 states a specific verb ('Edit') and resource ('a column'), and explicitly names the editable attributes ('title and/or color'). This clearly distinguishes it from sibling tools like create_column, delete_column, read_column, and set_default_column.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that read_column is for inspection, set_default_column handles default-column changes, or create/delete_column cover lifecycle operations. An agent must infer usage from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only safety signal. It discloses that issues survive, but it does not state that membership/card data is removed, whether the operation is reversible, what authorization is required, or how the target project board is identified given the schema lacks a project-board parameter.
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 short sentences, front-loaded with the essential action, and no filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and zero parameter descriptions, this description is too thin. It omits how the target board is selected, return behavior, and failure modes, leaving an agent to guess on critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only explains issue_numbers implicitly ('by number'). It does not add meaning to owner or repo, and it introduces an ambiguity about which project board is affected because the schema has no project board ID parameter.
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), the resource (issues by number from a project board), and scopes it to 'any project board'. It also distinguishes itself from delete_issue by asserting the issues themselves survive, so an agent can tell the tools apart.
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: when the goal is to detach issues from a project board without deleting them. It does not name sibling tools like delete_issue or add_issues_to_project, and gives no explicit when-not-to-use guidance.
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 the behavioral burden. It communicates that this is a retrieval operation and specifies the returned data, implying read-only behavior. It does not explicitly state that nothing is modified, nor does it mention permissions, pagination, or handling of empty columns.
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 short, front-loaded sentences with no filler. The first states the purpose and the second adds concrete return-field detail, so both sentences earn their 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?
For a simple read operation with no output schema, the description gives enough of the return shape to interpret results: column ids/titles and per-card issue id, number, and title. It omits edge cases like empty columns or project metadata, but the core information needed to call and use the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for missing parameter explanations. It does not define owner, repo, or project_id beyond the schema's bare names, and it does not say how to obtain a project_id or what formats are expected.
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 uses a specific verb ('Get') with a clear resource ('a project board') and details what is included: columns and cards/issues. It does not explicitly differentiate from the sibling read_project, but the scope is clear.
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 this is the tool to use when you need a project board with its columns and cards. However, it gives no explicit guidance about when not to use it or how it compares to alternatives like list_projects or read_project.
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 the full burden and does disclose the main side effects: creating the issue, optionally adding it as a card, and attaching milestone/labels/assignees. However, it says nothing about the return value, failure behavior (e.g., invalid project_id), or whether placement on the board has any other consequences.
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 compact sections with zero filler. The core purpose is front-loaded in the first sentence, and the Args block is a tight list where each line adds distinct value for an optional parameter.
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 an 8-parameter tool with no annotations and no output schema, the description covers the core purpose and optional attributes but omits the return format (what the created issue yields) and any integration hints for resolving label/project/assignee ids against sibling list tools. It is serviceable but leaves meaningful gaps an agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates for 4 of 8 parameters: project_id ('added to that project as a card'), milestone_id, label_ids, and assignee_ids. But the required params (owner, repo, title) and body have no semantic explanation, and 'Optional numeric ids' for labels/assignees is thin—it doesn't say what the ids reference or how to obtain them.
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 opening sentence 'Create an issue, optionally placing it directly on a project board' names a specific verb and resource, and the board-placement clause adds a distinguishing behavior. Against a sibling set containing delete_issue, create_project, create_milestone, and create_column, an agent can immediately tell which resource this acts on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to prefer this tool over alternatives. The sibling add_issues_to_project likely handles board placement for existing issues, but the description never routes between the two, nor does it state any prerequisites (e.g., project must exist before project_id can be used).
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 the full burden of behavioral disclosure. It correctly communicates the read-only nature of listing and the valid state filter values, but it omits any mention of response format, pagination, or ordering behavior, which are relevant for a list 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?
A single, well-structured sentence that front-loads the core action and immediately specifies the accepted state values. No filler or redundant wording.
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?
The description provides the essential purpose and state options, but for a tool with no output schema and no annotations, it is thin on return value details and pagination behavior. It is adequate for a simple list operation but leaves some operational context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does cover the 'state' parameter by listing its three possible values, but owner and repo are left to inference from their names. This is partial compensation for the schema gap.
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 clear verb ('List') and resource ('milestones in a repository'), and the explicit state values ('open', 'closed', or 'all') further define the scope. It is distinguishable from sibling list_repositories, which targets a different resource (repositories vs. milestones).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description: if an agent needs milestones for a repository, this is the tool. However, there is no explicit guidance on when not to use it or how it compares to alternatives, though no direct sibling for milestones exists among the provided tools.
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 the behavioral disclosure burden. It conveys that the operation is a read-only list and specifies the state filter ('open', 'closed', or 'all'), which is helpful. However, it does not mention pagination, return format, ordering, or any potential side effects, leaving some behavioral 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 compact and front-loaded with the core purpose, followed by a concise Args block. Every line carries necessary information and there is no filler or repetition.
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 listing tool, the description covers the key aspects: what is listed, where, and the optional filter. It lacks mention of return shape or pagination, but the absence of an output schema and the low complexity make this a minor gap rather than a critical deficiency.
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 provides no parameter descriptions (0% coverage), so the description must compensate. It does: owner is clarified as repository owner (user or org), repo as repository name, and state with its allowed values. This adds meaningful semantics beyond the bare schema titles.
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 clearly states the verb ('List'), the resource ('projects (kanban boards)'), and the scope ('in a repository'). It is unambiguous about what the tool does, though it does not explicitly distinguish itself from sibling tools like list_milestones or list_repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_project, create_project, or list_repositories. The description implies usage by stating it lists projects in a repository, but it does not provide any explicit when-to-use or when-not-to-use 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?
With no annotations provided, the description must carry the behavioral burden. It explains the main effect of setting the default column, but it does not disclose side effects such as replacing an existing default, required permissions, or whether the operation can be reversed.
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, focused sentence with no filler. The action and outcome are front-loaded, and the parenthetical adds useful context without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a required-parameter mutation tool with no annotations and no output schema, this description is too thin. It leaves out usage conditions, parameter details, response behavior, and potential side effects, so an agent would still lack important context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It clarifies that column_id refers to the default column and project_id to the project, but it does not explain owner, repo, or the relationships between the four required parameters.
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 ('Set') and resource ('column as the project's default'), and the parenthetical '(where new cards land)' explains the functional consequence. This clearly differentiates it from sibling tools like edit_column or delete_column.
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 the tool: when a user wants new cards to land in a particular column. However, it does not explicitly state alternatives, prerequisites, or situations where the tool should not be used.
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 the burden of behavioral disclosure. 'Permanently delete' conveys irreversibility, and the note about issues is valuable, but it does not mention permission requirements, side effects on related resources beyond issues, or what happens to the project's association with repos.
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 short sentences with no filler. The primary action is front-loaded, and the important scoping caveat about issues follows immediately without redundancy.
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 delete operation, the description captures the core destructive behavior and the non-deletion of issues. However, the absence of annotations, no output schema, and lack of usage guidance leave gaps around expected response, side effects, and when to prefer close_project instead.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level guidance. The parameter names owner, repo, and project_id are self-explanatory to some extent, but the description does not clarify ownership scope, required formats, or how project_id relates to a specific repo.
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 states a precise verb and resource ('Permanently delete a project') and adds a critical boundary ('This does not delete its issues'). This clearly distinguishes deletion from sibling operations like update_project, close_project, and reopen_project.
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 the tool is for destructively removing a project while preserving its issues, but it does not explicitly state when to choose this over close_project or mention any prerequisites. Usage context is only implied, not fully delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states that it creates a project/kanban board; it does not disclose side effects, permissions, idempotency, or what happens after creation. The verb 'Create' implies mutation but adds little beyond the tool name.
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 front-loaded purpose sentence followed by a compact parameter list with one line each. Every line adds necessary information and none is wasted.
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 create operation with five straightforward parameters and no output schema, the description covers all required inputs and their meanings. It does not discuss return values or preconditions, but the tool is simple enough that this is a minor gap.
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 description coverage is 0%, but the description explicitly explains every parameter: owner, repo, title, description, and card_type. It even enumerates card_type's allowed values ('text' or 'images_and_text'), which is valuable beyond the schema's plain 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 uses a specific verb and resource: 'Create a new project/kanban board in a repository.' It clearly distinguishes this from sibling update, close, reopen, delete, and list operations by naming the creation action and resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any when-to-use guidance or alternatives. It does not mention that this is for setting up a project as opposed to a column, issue, or milestone, though the resource name makes it somewhat 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 the full burden. It discloses the most important consequence (cards return to the default/uncategorized column), which is strong for a destructive tool. It does not state irreversibility, permission requirements, or response/error behavior, leaving some 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?
Two short sentences with the core action front-loaded and the key side effect second. There is no filler or repetition, so every sentence 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?
For a simple delete operation, this is largely complete: purpose, required entity, and the main side effect are all present. It would be more complete with explicit permissions/irreversibility or return-value guidance, but an agent can select and invoke the tool correctly from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-specific guidance beyond referring to 'a column.' The parameter names owner, repo, project_id, and column_id are somewhat self-explanatory, but the description fails to compensate for the missing schema documentation.
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 states a precise action and resource ('Delete a column') and immediately adds a distinguishing behavioral detail: cards are not lost but moved to default/uncategorized. This distinguishes it from edit_column, delete_project, and move_card.
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 intended use is implied: call this when a column should be removed. The card-relocation sentence gives useful context for deciding whether it is appropriate, but it does not explicitly contrast with alternatives such as edit_column or delete_project, nor state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It usefully adds the 'YYYY-MM-DD' deadline format and the partial-update implication of 'and/or', but it does not disclose effects on unspecified fields, null-clearing behavior, required permissions, or the response shape after a successful edit.
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 compact sentence with no filler. The date-format constraint is placed at the point where deadline is mentioned, making the most behaviorally relevant detail easy to notice.
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 mutation tool with no output schema and no annotations, the essential fields and value format are present, but the description does not cover important operational context such as whether omitted fields remain unchanged or how to clear a field by passing null. It is adequate but not 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 gives no descriptions for individual properties, so the description must add meaning. It maps title, description, and deadline to the relevant properties and specifies the deadline format, but it leaves owner, repo, and milestone_id as implicit identifiers rather than explaining them.
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 a specific verb ('Edit'), names the resource ('a milestone'), and enumerates exactly what can be changed: title, description, and deadline. This cleanly separates edit_milestone from sibling operations like create_milestone, close_milestone, reopen_milestone, and delete_milestone.
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 that the tool is used when an existing milestone's fields need to be modified, but it never explicitly states when not to use it or which sibling to prefer. An agent must infer the selection from the tool name and sibling list rather than from 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?
The description discloses two important behavioral traits beyond the schema: cards to the same column are placed in the order listed, and the operation runs concurrently. These are critical for predicting execution behavior. However, it does not mention failure atomicity, error handling, or rate limits, and since no annotations are provided, the description carries the full burden.
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, front-loaded with the primary action, and uses a clear Args block for parameter details. Every sentence adds value, and the formatting improves scannability without unnecessary verbosity.
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 bulk move operation with no output schema, the description covers the core invocation semantics: what the moves list looks like, ordering, and concurrency. It does not explain project_id/owner/repo (though these are schema-defined), nor does it address partial failures or result reporting, but it is sufficient for an agent to construct a correct call in most cases.
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?
The description significantly compensates for the schema's weak 'moves' parameter definition. The schema only specifies an array of objects with integer additionalProperties, while the description defines the required keys ('issue_number' and 'column_id') and explains ordering behavior. This is essential semantic information missing from the schema.
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 clearly states the action 'Move many cards at once, each to its own column', identifying both the verb and resource. It distinguishes itself from the singular 'move_card' sibling by emphasizing bulk operation, though it doesn't explicitly name the alternative.
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 phrase 'Move many cards at once' implies the tool is intended for bulk scenarios, but it does not explicitly state when to use it versus the single-card 'move_card' or mention any exclusions. Usage guidance is present by implication rather than direct instruction.
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?
There are no annotations, so the description carries the burden. It clarifies the authorization scope ('current user can access') and implies a read-only listing operation, but does not disclose response format, pagination behavior beyond parameters, or error conditions.
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, front-loaded with the tool's purpose, and includes a tidy Args block. Every sentence contributes useful information with no filler.
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 listing tool with no annotations and no output schema, the description explains what it does, for whom, and all parameters. It could be more complete about return value shape or pagination semantics, but the essential information needed to invoke it correctly is present.
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 description coverage is 0%, but the description fully documents all three parameters: query as an optional name filter, limit as max results with default 50, and page as page number with default 1. This adds real meaning beyond the bare schema titles and defaults.
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 states a clear action and resource: 'List repositories the current user can access', with a specific purpose ('for choosing where to manage projects'). This is not a tautology and is distinguishable from the project/issue/milestone siblings.
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 phrase 'for choosing where to manage projects' gives an implied use case, but the description does not explicitly say when to prefer this tool over alternatives or when not to use it. No exclusions or alternative routing are provided.
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 behavioral disclosure burden. It warns that the call is network- and token-expensive and explains pagination via limit/offset. It does not describe return shape or error behavior, but the cost warning is meaningful and goes 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 compact and well-structured: purpose first, then parameters, then a clear cost warning. Every sentence earns its place, and the warning is front-loaded near the top.
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?
The description covers cost, pagination, and intended use, but with no output schema and no annotations it should do more to clarify the return value and the required identifying parameters. It is adequate for a straightforward read tool, yet leaves noticeable gaps.
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 description explains state, project, limit, and offset semantics, which adds real value beyond the bare schema. However, it leaves the required owner, repo, and milestone_id parameters undocumented, and schema description coverage is 0%, so the agent must infer core identifying fields from names alone.
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 first line, 'Full content of every issue attached to a milestone', uses a specific verb and resource and clearly distinguishes this tool from siblings like list_milestones. An agent can immediately tell this reads issues by milestone rather than listing milestones or projects.
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 operational guidance: avoid unless asked or necessary, and cap cost with limit/offset. It does not name alternative tools for comparison, so it stops short of a fully explicit when-versus-alternatives statement, 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?
With no annotations, the description carries the behavioral burden. It discloses that bodies and comments are omitted, that it is lightweight, and that the return includes count, error_count, issues, and errors, which reveals partial-failure behavior. This goes beyond a bare 'read issues' statement, though it does not mention authentication or rate-limit implications.
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 and well-structured: purpose, a one-sentence caveat, an Args line, and a Returns line. Key information is front-loaded, and every sentence contributes to selecting or invoking the tool correctly.
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 bulk read tool with no annotations and no output schema, the description covers the purpose, the key alternative, the state argument, and the return shape. However, the near-total lack of parameter semantics for the required issue_numbers parameter leaves a gap that makes the description less complete than it should be for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions and does not even list 'issue_numbers' in properties, leaving necessary semantics undocumented. The description only explains 'state' and its allowed values; the required parameters owner, repo, and especially issue_numbers are left to inference. Since schema coverage is near zero, the description should compensate for at least the main input, but it does not specify the expected format for issue_numbers.
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 first sentence states a specific verb ('Read'), a specific resource ('issues'), and the scope ('many issues at once'), and it enumerates the exact summary fields returned. The phrasing clearly distinguishes it from read_card, which is the sibling for full content, so an agent knows what this tool is for without ambiguity.
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 read_card for full content', naming the alternative and the condition for choosing it instead. It also explains the state filter and its default, giving clear guidance on when to use this tool to filter results versus reading individual issue details elsewhere.
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 does this well by revealing that the tool reads credentials from specific environment variables, may authenticate on demand, and persists the session under the OS config directory. This goes beyond the surface-level 'status' meaning of the name.
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 short sentences, front-loaded with the core purpose, followed by the side effects and credential details. No redundant wording or filler.
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 zero-parameter status tool with no output schema, the description conveys the essential purpose, credential sources, and side-effect behavior. It could be slightly more explicit about the exact return format (e.g., a boolean), but 'Report whether' is reasonably sufficient for an agent to use 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 tool has zero parameters, so there is no parameter semantics to add. The description instead usefully explains the credential sources (FORGEJO_URL / FORGEJO_USERNAME / FORGEJO_PASSWORD), which is the closest analog to parameter documentation here.
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 ('Report whether') and a precise resource ('the MCP is authenticated to the Forgejo instance'). This clearly distinguishes it from the sibling 'authenticate' tool, which handles authentication itself.
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 this is the right tool for checking authentication status before other operations, and it notes that authentication happens automatically if needed. However, it does not explicitly contrast it with the sibling 'authenticate' tool or state when one should be preferred over the other.
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 must carry the full burden. It does well by disclosing the expensive nature (network- and token-intensive) and the scope of data fetched (full content, all comments). It does not detail pagination, rate limits, or failure behavior, but the cost disclosure is a strong and operationally useful behavioral trait 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?
Three sentences with zero waste. The first sentence defines the resource and return fields, the second carries the critical cost warning with a clear directive. The warning is front-loaded appropriately, giving the agent immediate operational 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?
For a read tool with three simple required parameters, the description covers the core purpose, return content, and cost implications. It doesn't mention pagination (if any), rate limiting, or that 'number' could be an issue number or PR number, but the output schema is absent, and the description does a reasonable job of covering the main concerns for an agent deciding to call 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?
The schema description coverage is 0%, so the description must compensate. It mentions the three parameters (owner, repo, number) implicitly by noting 'one card/issue' and the field list. However, it does not explain that owner is the GitHub account, repo is the repository name, or that number is the numeric issue/card ID. The schema itself provides no descriptions, so the description provides some context but not complete 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 that the tool reads the full content of one card/issue, specifying the exact fields returned (title, state, body, milestone, comments) and the unique identifier parameters. This distinguishes it from sibling tools like read_milestone and read_project by emphasizing it's for a single card/issue with full content.
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 warns that the operation is network- and token-expensive, and advises avoiding unless asked or necessary. This provides clear usage context for when to invoke this tool. However, it doesn't explicitly name alternative tools (e.g., a lighter-weight list tool) for cases where full content isn't needed, though the cost warning serves a similar purpose.
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 behavioral burden itself. It discloses a non-obvious trait: 'Network- and token-expensive,' and offers a mitigation strategy. It also documents filtering state/milestone and pagination via limit/offset, giving an agent useful expectations 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 compact and well-structured: a one-line purpose, a focused Args block, and a cost warning. Every sentence adds value, and the key warning is prominently placed at the end.
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 read tool with no output schema and no annotations, the description covers the main behaviors an agent needs: what is returned, how to filter, pagination, and a cost warning. It does not explain the exact structure of 'full content' or the meaning of the required project/column IDs, but these are partially inferable from the schema and sibling tool names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for state, milestone, limit, and offset, including allowed values and defaults, but does not describe owner, repo, project_id, or column_id. These four required parameters are left to be inferred from their names, so compensation is only partial.
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 and resource: 'Full content of every card in a column.' This unambiguously identifies the tool's scope and distinguishes it from siblings such as read_card, which targets a single card. The resource is clear and the action is concrete.
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 when NOT to use it: 'Avoid unless asked or necessary' and advises using limit/offset to control cost. It gives clear context, but it does not name alternative sibling tools or specify conditions under which a sibling would be preferred.
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 the full burden. It discloses key behavior: it caches the session and the force parameter allows a fresh login. However, it omits how authentication is performed, what happens on failure, or where the session is stored, which are important for an auth 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 compact: one clear purpose sentence and one parameter explanation. No wasted words, and the key information 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?
For a one-parameter auth tool with no output schema and no annotations, the description covers the core behavior and parameter semantics. It could mention that authentication is a prerequisite for sibling tools, but the session-caching clue makes that reasonably inferable.
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 description coverage is 0%, and the description fully compensates for the single parameter. It explains that force=true ignores the cached session and logs in fresh, which implies the default reuses the cache. This is complete and goes beyond the bare schema type and default.
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 states a specific verb and resource: 'Authenticate to Forgejo and cache the session.' This clearly distinguishes the tool from all siblings, which are project, milestone, and issue operations rather than authentication.
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 this is the gateway to Forgejo operations by mentioning session caching, and there are no alternative auth tools among siblings. However, it does not explicitly state that this should be called before other tools or that a cached session is automatically reused unless force is set.
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 behavioral disclosure burden. It warns that the call is network- and token-expensive and that it reads every column and card, which is valuable beyond what the name implies. It does not discuss auth requirements or the exact response format, but it covers the most important behavioral caveat for this read 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 compact and front-loaded: the purpose is stated first, followed by a tight Args list and a clear cost warning. Every sentence earns its place, with no repetition of schema details or filler.
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 tool with no output schema, no annotations, and seven parameters, the description provides enough context to invoke it correctly: full board scope, arg semantics, defaults, and cost mitigation. It does not describe the exact nested response shape, but 'every column and every card's content' gives a reasonable expectation of the return payload.
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 0%, so the description must explain parameters, and it does for the non-obvious ones: state values, milestone filtering, limit as max cards, and offset for paging. Required params like owner, repo, and project_id are self-explanatory, so the coverage is sufficient despite not naming every parameter explicitly.
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 and complete statement: 'Full content of an entire board: every column and every card's content.' This clearly identifies the resource and scope, and the emphasis on 'entire board' separates it from sibling tools like read_card and read_column.
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: this is a heavy, expensive operation, and it should be avoided unless explicitly requested or necessary. It also suggests using limit/offset to cap cost. It does not name alternatives like read_card or read_column for smaller reads, so it stops short of a full when-to-use-versus-alternatives explanation.
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:

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

Score Badge

Copy to your README.md:

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

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/UnwantedForeignCloudProvider/ForgejoProjectsMCP'

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