MeshArc

List a project's runs

list_runs

Read-onlyIdempotent

List a project's runs, newest first, with each run's id, status, trigger, pages read and pages changed. Use it to find a run_id for list_pages or get_changes, to check whether a run is still going before start_run, or to find the run to stop with cancel_job. get_project shows only the last run. Inputs: project_id from list_projects. limit=5 finds the latest few; runs past the limit cannot be paged. Errors: an unknown project answers 404. Read-only and free: it reads stored data and never fetches.

Input Schema

Name	Required	Description	Default
`limit`	No	How many runs to return, 1 to 100 (default 25).
`project_id`	Yes	The project's 32-character hex id, from list_projects.

Output Schema

Name	Required	Description
`code`	No	Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.
`runs`	No	Each {id, status, trigger, scope, pagesN, changedN, counts, coverage, stop, startedAt, elapsed, baseline, rebaselined}; baseline is a first run with nothing to compare, rebaselined one whose settings changed how pages read, so it was recorded rather than compared.
`error`	No	Only when the call failed: what went wrong, in words an assistant can act on.
`detail`	No	Only on a failure: the API's own wording, when the error was rephrased.
`status`	No	Only on a failure: the HTTP status code.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 7, 2026

changedInput schema / properties / limit / description

Previous value: -"How many runs to return, newest first: 1 to 100 (default 25)."New value: +"How many runs to return, 1 to 100 (default 25)."

changedInput schema / properties / project_id / description

Previous value: -"The project's id, as list_projects or create_project returns it."New value: +"The project's 32-character hex id, from list_projects."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "A project's runs, newest first.",
+  "properties": {
+    "code": {
+      "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.",
+      "title": "Code"
+    },
+    "detail": {
+      "description": "Only on a failure: the API's own wording, when the error was rephrased.",
+      "title": "Detail"
+    },
+    "error": {
+      "description": "Only when the call failed: what went wrong, in words an assistant can act on.",
+      "title": "Error"
+    },
+    "runs": {
+      "description": "Each {id, status, trigger, scope, pagesN, changedN, counts, coverage, stop, startedAt, elapsed, baseline, rebaselined}; baseline is a first run with nothing to compare, rebaselined one whose settings changed how pages read, so it was recorded rather than compared.",
+      "title": "Runs"
+    },
+    "status": {
+      "description": "Only on a failure: the HTTP status code.",
+      "title": "Status"
+    }
+  },
+  "title": "RunsOut",
+  "type": "object"
+}

AddedOct 7, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint/openWorldHint, so the safety profile is covered. The description still adds real operational context beyond them: results are ordered newest-first, runs past the limit cannot be paged, an unknown project returns 404, and the read 'never fetches'.

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?

Short labeled blocks (usage, Inputs, Errors, cost) keep it front-loaded, and every sentence contributes distinct information. Nothing is redundant with the schema or annotations.

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?

For a two-parameter read tool with full schema coverage, an output schema, and safety annotations, the description covers routing, ordering, limit behavior, and error semantics. Nothing an agent needs to select or call it correctly is missing.

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 project_id and limit are already documented. The description adds provenance ('project_id from list_projects') and a concrete tuning hint ('limit=5 finds the latest few'), plus the non-paging consequence of limit that the schema does not state.

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+resource ('List a project's runs, newest first') and enumerates the fields returned (id, status, trigger, pages read/changed). It also distinguishes itself from the sibling get_project by noting that get_project shows only the last run.

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 names three when-to-use cases and the corresponding alternatives: finding a run_id for list_pages/get_changes, checking an in-flight run before start_run, and locating the run to stop with cancel_job. No exclusion or alternative is left to inference.

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

All MeshArc tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.