Skip to main content
Glama

analyze_tasks

Read-only

Analyzes the HONESTY of the project's tracking (tasks and arbitrations): finds the places where the tracking announces OPEN what is closed, or leaves a question unanswered. Useful WHEN RESUMING a run, before relying on list_tasks. Rules run: arbitrage-sans-reponse (an arbitration that is done or archived whose cycle stayed stuck — the decision was made elsewhere and never recorded) · arbitrage-ouvert-ancien (question at the "propose" step unanswered for N days) · clarification-sans-reponse ("more explanation" request not served for N days) · epic-sous-tache-desaccord (done Epic with a live subtask that is not done, or open Epic whose live subtasks are all done, as a QUESTION) · doing-immobile ("doing" task untouched for 3 days: the status may have diverged from the real work; a missing or unreadable date stays SILENT; a task labeled a-valider or a-approuver waits for a human and is never reported) · plan-ouvert-sans-sous-tache-ouverte (root labeled plan, without a parent, still open although none of its subtasks is: warning if it has some and all are closed or archived, info as a QUESTION if it has none) · plan-remplace-ouvert (open task labeled plan-remplace: a superseded plan does not stay open) · done-non-archive-ancien (OPT-IN via doneNotArchivedDays). Each finding carries severity (warning = established defect; info = question), message in English and suggestion (the action that answers it). measures returns the distribution of ages (min/median/max, in days) of open arbitrations and pending explanation requests — the measurement behind the thresholds: re-measure before tightening them. ⚠️ WHAT IT DOES NOT DO, said in notChecked of the response: does not compare any task text to a repository (cited paths, migrations) or to a language (meeting-minutes titles) — those rules belong to the OrgGen tracking project, does not read the CONTENT of tasks beyond the arbitration cycle, and does not look at the tasks of linked projects. A finding is a SIGNAL TO VERIFY rather than a verdict: nothing is blocked, nothing is written, and doubt (unreadable date, corrupted cycle) stays silent. Modifies nothing.

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of findings returned (default: 50, max: 200).
cellIdNoLimits the analysis to the tasks of THIS block AND of its child blocks (not this block alone). Omitted: the whole project. The Epic/subtask rule is relational: it looks at the whole project in every case and returns only the findings whose faulty task is within the scope.
offsetNoPagination — number of findings to skip (default: 0).
includeInfoNoAlso returns the findings of `info` severity (questions asked, not established defects). Default: false — their COUNT is always returned in `infoHidden`.
arbitrationDaysNoThreshold, in days, of `arbitrage-ouvert-ancien`: a question left unanswered at the "propose" step. Default: 7. `measures.openArbitrations` gives the actual count to compare with this threshold.
clarificationDaysNoThreshold, in days, of `clarification-sans-reponse`: a "more explanation" request not served. Default: 3.
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.
doneNotArchivedDaysNoOPT-IN. Turns on `done-non-archive-ancien`: a task done for more than N days without being archived. Omitted: the rule is OFF (archiving is tidying, not doctrine).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / arbitrationDays / description
      Previous value: -"Seuil, en jours, de `arbitrage-ouvert-ancien` : une question restée sans réponse à l’étape « propose ». Défaut : 7. `measures.openArbitrations` donne le compte réel à confronter à ce seuil."New value: +"Threshold, in days, of `arbitrage-ouvert-ancien`: a question left unanswered at the \"propose\" step. Default: 7. `measures.openArbitrations` gives the actual count to compare with this threshold."
    • changedInput schema / properties / cellId / description
      Previous value: -"Borne l’analyse aux tâches de CE bloc ET de ses blocs enfants (jamais ce bloc seul). Omis : le projet entier. La règle Epic/sous-tâche, relationnelle, regarde toujours tout le projet et ne rend que les constats dont la tâche fautive est dans le périmètre."New value: +"Limits the analysis to the tasks of THIS block AND of its child blocks (not this block alone). Omitted: the whole project. The Epic/subtask rule is relational: it looks at the whole project in every case and returns only the findings whose faulty task is within the scope."
    • changedInput schema / properties / clarificationDays / description
      Previous value: -"Seuil, en jours, de `clarification-sans-reponse` : une demande « plus d’explications » non servie. Défaut : 3."New value: +"Threshold, in days, of `clarification-sans-reponse`: a \"more explanation\" request not served. Default: 3."
    • changedInput schema / properties / doneNotArchivedDays / description
      Previous value: -"OPT-IN. Allume `done-non-archive-ancien` : une tâche terminée depuis plus de N jours sans être archivée. Omis : la règle est ÉTEINTE (l’archivage est du rangement, pas une doctrine)."New value: +"OPT-IN. Turns on `done-non-archive-ancien`: a task done for more than N days without being archived. Omitted: the rule is OFF (archiving is tidying, not doctrine)."
    • 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 / includeInfo / description
      Previous value: -"Rend aussi les constats de sévérité `info` (questions posées, pas des défauts établis). Défaut : false — leur NOMBRE est toujours rendu dans `infoHidden`."New value: +"Also returns the findings of `info` severity (questions asked, not established defects). Default: false — their COUNT is always returned in `infoHidden`."
    • changedInput schema / properties / limit / description
      Previous value: -"Nombre de constats rendus (défaut : 50, max : 200)."New value: +"Number of findings returned (default: 50, max: 200)."
    • changedInput schema / properties / offset / description
      Previous value: -"Pagination — nombre de constats à sauter (défaut : 0)."New value: +"Pagination — number of findings to skip (default: 0)."
  2. Changed1 schema field changed
    • changedInput schema / properties / arbitrationDays / description
      Previous value: -"Seuil, en jours, de `arbitrage-ouvert-ancien` : une question restée sans réponse à l’étape « propose ». Défaut : 7. Compare avec `measures.openArbitrations` avant de le resserrer."New value: +"Seuil, en jours, de `arbitrage-ouvert-ancien` : une question restée sans réponse à l’étape « propose ». Défaut : 7. `measures.openArbitrations` donne le compte réel à confronter à ce seuil."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With readOnlyHint already declared, the description still adds substantial context: 'Modifies nothing', nothing is blocked, doubt stays silent (unreadable dates, corrupted cycles), signals are 'SIGNAL TO VERIFY rather than a verdict'. It also discloses severity taxonomy, the infoHidden count behavior, and explicit exclusion zones in notChecked.

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?

Purpose and usage are front-loaded, then rules and caveats follow in a deliberate order with separators. The single dense paragraph is long, but nearly every clause carries rule or behavior information an agent needs; only minor redundancy (restating 'nothing is written/blocked') keeps it from a 5.

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?

There is no output schema, and the description compensates fully: it documents the finding shape (severity, message, suggestion), the measures block, the notChecked disclosures, and the infoHidden count. For an 8-parameter read-only analysis tool, an agent has everything needed to call and interpret it.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it ties arbitrationDays/clarificationDays to measures.openArbitrations and advises re-measuring before tightening, and clarifies doneNotArchivedDays is OPT-IN and OFF by default. It doesn't restate the limit/offset/cellId semantics already well covered by 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 (analyzes the honesty of task/arbitration tracking) and defines the concrete deliverable: places where tracking announces OPEN what is closed or leaves a question unanswered. It also names the sibling it complements ('before relying on list_tasks'), so an agent can distinguish it from plain listing tools.

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 says when to reach for it ('useful WHEN RESUMING a run, before relying on list_tasks'), names the alternative, and enumerates the exact rules that fire. It also states what it does not do ('does not compare task text to a repository... does not read CONTENT... does not look at linked projects'), giving real when-not guidance.

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.