Skip to main content
Glama

report

Read-onlyIdempotent

Retrieve the most recent build's structured summary: task outcomes, per-file edits, failed commands, governance escalations, unmet goals, token/cost totals, and per-model success rates.

Instructions

Return the latest build report, audit trail, and model performance.

Use when: a ``build`` or ``run`` has finished (or was stopped) and you want
the outcome — which tasks completed/failed/deferred, per-file edits, failed
commands, governance escalations, unmet-goal gaps, token/cost totals, and
per-model success rates. This is misterdev's read-only equivalent of asking
"what did the last run find and do?". Do NOT use when: nothing has been
built yet — ``latest_report`` will be null. Related: ``status`` (live task
states), ``build``/``run`` (produce a report).

Side effects: none — reads only the project's ``.orchestrator`` artifacts,
calls no LLM, and returns the same result on repeated calls (idempotent).

Returns an object with ``latest_report`` (the most recent build's structured
summary, or null), ``audit`` (command/edit/governance counts), and
``models`` (per-model attempts, success rate, and average cost). Returns an
``error`` field instead when ``path`` is not an existing directory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to a project directory that has been built at least once. Reads only misterdev's own ``.orchestrator`` artifacts under it. Example: '/Users/me/code/my-api'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds concrete behavioral details: 'reads only the project's .orchestrator artifacts, calls no LLM, and returns the same result on repeated calls (idempotent).' Also notes error handling when path is invalid. No contradiction with annotations.

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?

The description is well-structured: lead sentence, when-to-use section, side effects, and return value summary. It is appropriately sized for the tool's complexity, with every sentence contributing useful information. No fluff.

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?

Given the tool has only one parameter and an output schema (not shown but present), the description covers all necessary aspects: prerequisites, return structure (latest_report, audit, models, error), and side effects. It is complete for an agent to use correctly.

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% and the schema already describes the 'path' parameter well. The main description adds the error condition context ('Returns an error field instead when path is not an existing directory'), which provides additional meaning beyond the schema. Score 4 reflects this added value.

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?

The description starts with a clear verb+resource: 'Return the latest build report, audit trail, and model performance.' It distinguishes from sibling tools like 'status' (live task states) and 'build'/'run' (produce a report), ensuring the agent knows exactly what this tool does.

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?

Explicit usage guidance: 'Use when: a build or run has finished... Do NOT use when: nothing has been built yet...' and names related tools ('status', 'build', 'run') as alternatives. This leaves no ambiguity about when to invoke.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dcondrey/misterdev'

If you have feedback or need assistance with the MCP directory API, please join our Discord server