Skip to main content
Glama
Sign In

OrgGen AI

by ai.orggen
OverviewDiscussionsAdmin

list_roadmap

Read-only

Reads the ROADMAP of the project: the blocks that the governing roles have sorted into three horizons — Now (now), Next (next), Later (later) — in their order, with their milestone mark if any, plus the horizon suggestions PENDING a decision. ⚠️ It is a TEAM commitment set by a human, not a forecast: no horizon displays a date, and a block never sorted does not appear there (this is not an oversight, it simply has no horizon). Only blocks that still exist in the schema are returned. ⚠️ As long as the roadmap is not served on this project, the call SAYS so (roadmap_unavailable) instead of returning an empty roadmap: an empty roadmap and an absent roadmap are not the same thing. An agent READS the horizon; it does not set it — a change is proposed through suggest_horizon.

Input Schema

NameRequiredDescriptionDefault
onlyNoRestricts the response to one horizon: now (Now), next (Next) or later (Later). Omitted: all three.
expectedProjectIdNoUUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted.
includeSuggestionsNoAlso return the PENDING suggestions (default: yes). `false` omits them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / expectedProjectId / description
      Previous value: -"UUID du projet visé par CET appel. Cible RÉELLEMENT ce projet au lieu du projet de session. Refusé sans rien modifier si l'accès n'est pas accordé."New value: +"UUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted."
    • changedInput schema / properties / includeSuggestions / description
      Previous value: -"Rendre aussi les suggestions EN ATTENTE (défaut : oui). `false` les omet."New value: +"Also return the PENDING suggestions (default: yes). `false` omits them."
    • changedInput schema / properties / only / description
      Previous value: -"Ne rendre qu’un seul horizon : now (Maintenant), next (Ensuite) ou later (Plus tard). Omis : les trois."New value: +"Restricts the response to one horizon: now (Now), next (Next) or later (Later). Omitted: all three."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds substantial context beyond that: no horizon carries a date (it's a human commitment, not a forecast), only surviving schema blocks are returned, and empty vs absent roadmap is an explicit distinction with a named error key.

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?

Front-loads the core purpose and the horizons before the warnings. Dense but mostly earns its length; the repeated warning emphasis (⚠️ twice) is slightly heavy for the information conveyed.

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 fully describes the return shape — horizons, ordering, milestone marks, pending suggestions, and the unavailable case. An agent knows both what it will get and when it will get an error instead.

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 the schema already explains `only`, `expectedProjectId`, and `includeSuggestions` in detail. The description adds nothing specific about parameters, and the baseline 3 applies when the schema carries the full burden.

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 ('Reads the ROADMAP of the project') and immediately scopes it: the three horizons in order, milestone marks, and pending suggestions. It clearly distinguishes itself from the mutation sibling by noting the agent reads rather than sets horizons.

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?

Explicitly routes the agent: to change a horizon, use `suggest_horizon`. It also documents the when-not case — if the roadmap isn't served, the call reports `roadmap_unavailable` — and notes that unsorted blocks are intentionally absent, so the agent doesn't mistake omission for error.

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

All OrgGen AI 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