MeshArc

List all projects

list_projects

Read-onlyIdempotent

List every project in the workspace, the sites it watches over time, each with its id, name, host, schedule, page count, coverage, last run and status; and the workspace's plan and the credits it has left. Call it first to find the project_id the other project tools take, to check a site is not already watched before create_project, or to see whether there are credits for a large crawl. get_project reads one project in full. Results: every project in one answer, oldest first, with no paging. A key limited to some projects sees only those. Read-only and free: it reads stored data and never fetches.

Input Schema

Name	Required	Description	Default
No arguments

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.
`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.
`projects`	No	Oldest first, each {id, name, seed, host, schedule, pages, coverage, lastRun, status}; status is draft, crawling, healthy or failing.
`workspace`	No	{plan, creditsLeft, creditsSpentThisMonth, oneTimeAllowance}: creditsLeft is what may still be spent, this month or, on a one-time allowance, ever; null means no limit. {note} instead when the balance could not be read.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

addedOutput schema / properties / workspace

Added value: +{
+  "description": "{plan, creditsLeft, creditsSpentThisMonth, oneTimeAllowance}: creditsLeft is what may still be spent, this month or, on a one-time allowance, ever; null means no limit. {note} instead when the balance could not be read.",
+  "title": "Workspace"
+}

Changed10 schema fields changedOct 7, 2026

addedOutput schema / additionalProperties
```
Added value: +true
```

addedOutput schema / description

Added value: +"Every project the key can see."

addedOutput schema / properties / code

Added value: +{
+  "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.",
+  "title": "Code"
+}

addedOutput schema / properties / detail

Added value: +{
+  "description": "Only on a failure: the API's own wording, when the error was rephrased.",
+  "title": "Detail"
+}

addedOutput schema / properties / error

Added value: +{
+  "description": "Only when the call failed: what went wrong, in words an assistant can act on.",
+  "title": "Error"
+}

addedOutput schema / properties / projects

Added value: +{
+  "description": "Oldest first, each {id, name, seed, host, schedule, pages, coverage, lastRun, status}; status is draft, crawling, healthy or failing.",
+  "title": "Projects"
+}

removedOutput schema / properties / result

Removed value: -{
-  "anyOf": [
-    {
-      "items": {},
-      "type": "array"
-    },
-    {
-      "additionalProperties": true,
-      "type": "object"
-    }
-  ],
-  "title": "Result"
-}

addedOutput schema / properties / status

Added value: +{
+  "description": "Only on a failure: the HTTP status code.",
+  "title": "Status"
+}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"list_projectsOutput"New value: +"ProjectsOut"

First observedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only and idempotent, but the description adds substantive context beyond them: no paging, oldest-first ordering, key-scoped visibility ('a key limited to some projects sees only those'), and the fact that it never fetches remote data and costs nothing. These are non-obvious behaviors an agent would otherwise have to discover.

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-loaded with the action and routing guidance before the enumerated return fields. The single long middle sentence enumerating project fields is dense but each clause maps to real output content, so it earns its space.

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?

An output schema exists, yet the description still usefully previews returned fields plus workspace plan and credit balance, and adds scoping and ordering behavior the schema cannot convey. Nothing an agent needs to call this 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the empty schema is self-explanatory.

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 ('List every project in the workspace') and immediately contrasts with the sibling that reads a single project ('get_project reads one project in full'). An agent can distinguish it from get_project without opening a 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 three concrete when-to-use conditions: find the project_id other tools need, verify a site isn't already watched before create_project, and check available credits before a large crawl. It also names get_project as the alternative for single-project detail.

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.