Skip to main content
Glama

Tus proyectos

list_projects
Read-only

Lista los proyectos del usuario: en qué punto va cada uno (state), el siguiente paso (next), sus tareas abiertas (las vencidas, marcadas) y sus últimos avances. Úsala cuando pregunte en qué estaba, qué tiene pendiente o qué toca ahora, y antes de crear un proyecto, para no repetirlo. Con id, los datos de uno entero para que los leas tú; para enseñárselo al usuario, project_info. Antes de trabajar con sus proyectos, carga la skill proyectos con get_skill.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_projects"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoUn proyecto (p1, p2…) para verlo entero.
allNoIncluir también los hechos.
brainNoLa práctica que comparte un cerebro conectado (u-xxxxxx): sus gotchas, runbooks, formatos, aprendizajes y decisiones sueltas. No son del usuario. Con id, la de un proyecto.
outputNoCon id: un output (o1, o2…) entero, con sus versiones anteriores.
archivedNoSolo los nombres de los proyectos archivados. Úsalo solo si el usuario pregunta por ellos.
open_archivedNoCon id: abrir un proyecto archivado. Solo si el usuario lo ha pedido en este mensaje; nunca por tu cuenta ni como contexto de otra tarea.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / brain
      Added value: +{
      +  "description": "La práctica que comparte un cerebro conectado (u-xxxxxx): sus gotchas, runbooks, formatos, aprendizajes y decisiones sueltas. No son del usuario. Con id, la de un proyecto.",
      +  "type": "string"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / archived
      Added value: +{
      +  "description": "Solo los nombres de los proyectos archivados. Úsalo solo si el usuario pregunta por ellos.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / open_archived
      Added value: +{
      +  "description": "Con id: abrir un proyecto archivado. Solo si el usuario lo ha pedido en este mensaje; nunca por tu cuenta ni como contexto de otra tarea.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / output
      Added value: +{
      +  "description": "Con id: un output (o1, o2…) entero, con sus versiones anteriores.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real context beyond that: that a skill must be loaded first before working with projects, and that the full-record read is intended for the agent rather than the user. It stops short of describing output shape or result size, which matters for the no-argument bulk listing.

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?

Front-loads what is returned, then when to use it, then the sibling routing and prerequisite — no filler. Every clause carries distinct information; the density of sibling names is justified by the ambiguity it resolves.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly front-loads the return shape (state, next, open tasks, last progress) so the agent knows what it will get. The prerequisite skill load, the archived-project caution, and the routing to project_info close the remaining gaps for a six-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every one of the six parameters already has its own description, so the baseline is 3. The description only adds intent for one parameter ('Con id, los datos de uno entero para que los leas tú'), leaving all, brain, output, archived and open_archived to 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 ('Lista los proyectos del usuario') and immediately enumerates the payload: state, next step, open tasks incl. overdue/flagged, and latest progress. It also distinguishes itself from the sibling project_info (read-it-yourself vs show-the-user), so an agent can tell them apart without opening either 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 concrete triggers ('cuando pregunte en qué estaba, qué tiene pendiente o qué toca ahora'), a preventive use case (antes de crear un proyecto, para no repetirlo), an explicit alternative for display (project_info), and a prerequisite (carga la skill proyectos con get_skill). When-to-use, when-to-use-something-else, and ordering are all covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.