Skip to main content
Glama
Sign In
GitHub MCP Server — AutomateHub

GitHub MCP Server — AutomateHub

by gnvidia06-ux
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Cerrar issue

close_issue

Close an existing GitHub issue and optionally add a comment explaining why it is resolved, completed, or no longer applicable.

Instructions

Cierra un issue existente de un repositorio de GitHub, opcionalmente dejando un comentario con el motivo. Usala cuando el usuario diga que un issue está resuelto, terminado o ya no aplica. Requiere el número del issue (si no lo sabés, primero usá list_issues).

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>",
      "issueNumber": "<issueNumber>"
    },
    "name": "close_issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoYesNombre del repositorio, sin el owner. Ejemplo: 'mi-proyecto'.
ownerNoUsuario u organización dueña del repositorio. Si se omite, se usa el usuario autenticado (dueño del token).
commentNoComentario opcional para dejar antes de cerrar (ej: el motivo del cierre).
issueNumberYesNúmero del issue tal como aparece en GitHub, sin el '#'. Ejemplo: 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
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: it does convey that this is a mutation that may post a comment as a side effect, and the schema clarifies the comment is left before closing. However, it says nothing about permissions/scopes required, what happens if the issue is already closed, or whether closing is reversible — meaningful gaps for a write operation.

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

Conciseness5/5

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

Three short sentences, front-loaded with the action, then usage condition, then the prerequisite. No redundant restatement of the title or schema fields.

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 purpose, trigger, and prerequisite for a 4-parameter mutation tool with no output schema. It falls short on behavioral context that nothing else supplies: authentication requirements, error behavior, and the result of the call are all 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 100%, so repo, owner, comment, and issueNumber are already documented with patterns and examples. The description only reinforces the issue-number requirement and points to list_issues, adding little beyond the schema.

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

Purpose5/5

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

States a specific verb and resource ("Cierra un issue existente de un repositorio de GitHub") plus the optional side effect of leaving a comment. This clearly separates it from siblings like create_issue, list_issues, and add_comment_to_issue.

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?

Gives explicit trigger conditions ("cuando el usuario diga que un issue está resuelto, terminado o ya no aplica") and names the alternative path when the issue number is unknown ("primero usá list_issues"). The agent knows both when to call it and what to do when it lacks the required identifier.

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

Deploy Server

Other Tools