Skip to main content
Glama
Sign In

md-doc

by com.md-doc.app
OverviewDiscussionsAdmin

issues_search

Busca issues por texto (título/contenido). Devuelve resúmenes {id, title, status, priority, folderId, updatedAt}. ISSUES: una issue es trabajo por hacer con un estado: open (abierta), in_progress (en progreso), test (en pruebas: hecha, falta comprobar que funciona) o done (completada y comprobada). Nota = cómo funciona algo; bitácora = qué pasó; issue = qué falta por hacer. Una issue no pertenece a ninguna nota: enlázala con lo que corresponda mediante chips ($[issue::<título>] desde otros recursos, y $[note::<título>], $[log::<título>]… en su content). Busca antes con issues_search/issues_list para no duplicar. Al empezar a trabajar en una pon status in_progress y, al terminarla, test con issues_update: NO la pases a done tú, salvo que el usuario te lo pida o hayas comprobado que funciona (tests, despliegue verificado…); en ese caso explica en el content o en la bitácora cómo lo comprobaste. Si al probarla falla, vuelve a in_progress. Lo hecho, además, va en su bitácora con log_append. Prioridad: low (baja), medium (media, por defecto), high (alta) o critical (crítica). Al crear una issue pon la prioridad que indique el usuario o la evidente (p. ej. algo caído en producción = critical); si no, déjala en medium. Cuando decidas en qué trabajar, empieza por critical y luego high; issues_list ya las devuelve en ese orden. Si la issue está en una carpeta compartida, cada cambio de estado se notifica por email a quienes tienen acceso: no cambies el estado sin motivo. Si una issue se ESTANCA (no está claro cuál es la solución correcta, o hay posturas enfrentadas), propón al usuario abrir una partida del MODO VS sobre ella (vs_open con issueId): otro modelo revisa tu solución y discutís hasta un acuerdo.

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": {
      "query": "<query>"
    },
    "name": "issues_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesTexto a buscar

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are supplied, so the description must carry behavior alone. It does disclose that matching is over title/content and enumerates the returned summary fields, but says nothing about result limits, pagination, ordering of search hits, or whether the operation is strictly read-only — significant for a search endpoint with zero annotation coverage.

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

Conciseness2/5

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

The purpose and return shape are front-loaded and efficient, but the bulk of the text is a domain tutorial about statuses, priorities, chips, email notifications and VS mode — most of it guidance for issues_create/issues_update/log_append rather than for a one-parameter text search, so much of it does not earn its place here.

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 single-parameter search with no output schema, the description fully covers what is searched and what comes back, which is the essential information. It is more than complete on domain context but still omits practical call details such as result caps or paging behavior.

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?

There is a single parameter with 100% schema description coverage, so the baseline is already 3–4; the description adds real meaning by clarifying that 'query' matches against title and content rather than, say, ids or folder 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?

Opens with a specific verb and resource ('Busca issues por texto'), names the fields searched (título/contenido) and states the exact return shape {id, title, status, priority, folderId, updatedAt}, which clearly separates it from siblings like issues_get or issues_list.

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?

Gives concrete context: search first with issues_search/issues_list to avoid creating duplicates, and notes that issues_list already returns items ordered by priority. It never states the explicit selection rule between issues_search (keyword lookup) and issues_list (browse) or issues_get (exact id), so the choice is left partly implicit.

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

All md-doc toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources