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

GitHub MCP Server — AutomateHub

by gnvidia06-ux
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Crear issue

create_issue

Create a new GitHub issue with a title, optional Markdown description, and labels to report bugs, track tasks, or log improvements.

Instructions

Abre un issue NUEVO en un repositorio de GitHub, con título y descripción opcional. Usala cuando el usuario quiera reportar un bug, registrar una tarea, pendiente o mejora en un repo. Si no se indica owner, se usa la cuenta del usuario autenticado. Para ver issues existentes usá list_issues; para comentar uno existente, add_comment_to_issue.

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>",
      "title": "<title>"
    },
    "name": "create_issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoDescripción detallada del issue. Acepta Markdown.
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).
titleYesTítulo del issue: resumen corto del problema o tarea.
labelsNoLista de etiquetas existentes a aplicar. Ejemplo: ['bug', 'urgente'].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the owner fallback (authenticated user) and makes clear this is a new-record creation, but it says nothing about required token scopes, whether duplicate titles are allowed, or what the call returns, which matters for a mutation tool.

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

Conciseness5/5

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

Three sentences, front-loaded with the action and resource, then the trigger condition, then the alternative routing. No filler and no repetition of the tool title.

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 5-parameter creation tool with a fully described schema and no output schema, the description covers purpose, triggers, alternatives and the owner default. It stops short of describing the result (issue number/URL) or failure modes, which would help an agent confirm the call succeeded.

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 every parameter including repo/owner split, body Markdown support and labels already has meaning in the schema. The description only echoes title/body and the owner default, adding little beyond the structured fields, so the baseline of 3 applies.

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 precise verb and resource ("Abre un issue NUEVO en un repositorio de GitHub") plus the fields it accepts, and explicitly differentiates itself from list_issues and add_comment_to_issue, so an agent can pick it without opening any schema.

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 an explicit when-to-use trigger (reportar un bug, registrar una tarea, pendiente o mejora) and names two alternatives with the conditions that select them: list_issues for reading, add_comment_to_issue for commenting on an existing one.

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