MeshArc

Update a project's settings

update_project

Destructive

Change a project's name, schedule or settings, its webhook among them, and send the webhook a test. Call get_project first to see the current values. To crawl with the new settings now, follow with start_run. A project's site cannot change: to watch another site use create_project. Inputs: project_id from list_projects. Only what you pass changes, and in config only the keys given, so config={"max_pages": 200} leaves every other setting alone. schedule='manual' stops scheduled runs. Valid keys come from get_project with no project_id. A webhook is config={"webhook_url": "https://example.com/hook", "webhook_events": ["run.finished", "page.changed"]}; webhook_url="" turns it off. test_webhook=true then queues a test run.finished message, and get_project shows whether it was delivered. Effect: it answers with the updated project. Nothing is fetched and no credits are spent. A replaced value is gone, not versioned. Changing how markdown is produced (e.g. only_main_content, include_tags, exclude_tags) makes the next run a new baseline, recorded rather than compared. Needs write access; a read-only connection is refused with code 'read_only'.

Input Schema

Name	Required	Description
`name`	No	A new name; omit to leave it.
`config`	No	Settings to change as {key: value}; omit to leave them all.
`schedule`	No	A new schedule; omit to leave it.
`project_id`	Yes	The project's 32-character hex id, from list_projects.
`test_webhook`	No	true sends a test run.finished message to the project's webhook URL, after any changes; the URL must be saved. Default false.

Output Schema

Name	Required	Description
`id`	No	The project's 32-character hex id.
`code`	No	Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.
`host`	No	The site it covers; fixed at creation.
`name`	No	Its display name.
`note`	No	No project_id only: how path globs work.
`seed`	No	Where its crawls start.
`error`	No	Only when the call failed: what went wrong, in words an assistant can act on.
`config`	No	Its settings as {key: value}; secrets such as chat_url come back masked.
`detail`	No	Only on a failure: the API's own wording, when the error was rephrased.
`pagesN`	No	Pages its last finished run read.
`status`	No	draft, crawling, healthy or failing. On an error, the HTTP status code.
`coverage`	No	Percent of the site the last run reached; under 90 means removals are withheld.
`settings`	No	No project_id only: every common setting as {key, meaning, default}.
`webhooks`	No	get_project only: {url, events, deliveries}: where run and change events are POSTed, which events, and the last 10 deliveries, each {id, event, status (queued, retrying, delivered or failed), attempts, lastStatus, lastError, createdAt, deliveredAt}. The signing secret is never included.
`lastRunAt`	No	When the last run started (ISO 8601), or null.
`nextRunAt`	No	When the schedule runs it next, or null for manual.
`retention`	No	How long runs are kept, e.g. '90d'.
`schedules`	No	No project_id only: the valid schedules.
`other_keys`	No	No project_id only: further keys accepted but rarely needed.
`scheduleKey`	No	manual, hourly, daily or weekly.
`webhookTest`	No	update_project with test_webhook only: {queued, id} when a test run.finished message was queued, or {error, status} when the API refused it, e.g. with no webhook URL saved.
`changeSummary`	No	The last compared run in words, e.g. '3 new · 2 changed · 0 removed'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 7, 2026

addedInput schema / properties / test_webhook

Added value: +{
+  "default": false,
+  "description": "true sends a test run.finished message to the project's webhook URL, after any changes; the URL must be saved. Default false.",
+  "title": "Test Webhook",
+  "type": "boolean"
+}

changedOutput schema / description

Previous value: -"A project, or with no project_id the settings any project can take."New value: +"A project, as get_project, create_project and update_project answer with it; get_project with no\nproject_id answers with the settings any project can take instead."

addedOutput schema / properties / webhookTest

Added value: +{
+  "description": "update_project with test_webhook only: {queued, id} when a test run.finished message was queued, or {error, status} when the API refused it, e.g. with no webhook URL saved.",
+  "title": "Webhooktest"
+}

addedOutput schema / properties / webhooks

Added value: +{
+  "description": "get_project only: {url, events, deliveries}: where run and change events are POSTed, which events, and the last 10 deliveries, each {id, event, status (queued, retrying, delivered or failed), attempts, lastStatus, lastError, createdAt, deliveredAt}. The signing secret is never included.",
+  "title": "Webhooks"
+}

Changed3 schema fields changedOct 7, 2026

changedInput schema / properties / config / description

Previous value: -"Settings to change, e.g. {\"max_pages\": 200}; keys not given keep their values. Omit to leave them all."New value: +"Settings to change as {key: value}; omit to leave them all."

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, or with no project_id the settings any project can take.",
+  "properties": {
+    "changeSummary": {
+      "description": "The last compared run in words, e.g. '3 new · 2 changed · 0 removed'.",
+      "title": "Changesummary"
+    },
+    "code": {
+      "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.",
+      "title": "Code"
+    },
+    "config": {
+      "description": "Its settings as {key: value}; secrets such as chat_url come back masked.",
+      "title": "Config"
+    },
+    "coverage": {
+      "description": "Percent of the site the last run reached; under 90 means removals are withheld.",
+      "title": "Coverage"
+    },
+    "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"
+    },
+    "host": {
+      "description": "The site it covers; fixed at creation.",
+      "title": "Host"
+    },
+    "id": {
+      "description": "The project's 32-character hex id.",
+      "title": "Id"
+    },
+    "lastRunAt": {
+      "description": "When the last run started (ISO 8601), or null.",
+      "title": "Lastrunat"
+    },
+    "name": {
+      "description": "Its display name.",
+      "title": "Name"
+    },
+    "nextRunAt": {
+      "description": "When the schedule runs it next, or null for manual.",
+      "title": "Nextrunat"
+    },
+    "note": {
+      "description": "No project_id only: how path globs work.",
+      "title": "Note"
+    },
+    "other_keys": {
+      "description": "No project_id only: further keys accepted but rarely needed.",
+      "title": "Other Keys"
+    },
+    "pagesN": {
+      "description": "Pages its last finished run read.",
+      "title": "Pagesn"
+    },
+    "retention": {
+      "description": "How long runs are kept, e.g. '90d'.",
+      "title": "Retention"
+    },
+    "scheduleKey": {
+      "description": "manual, hourly, daily or weekly.",
+      "title": "Schedulekey"
+    },
+    "schedules": {
+      "description": "No project_id only: the valid schedules.",
+      "title": "Schedules"
+    },
+    "seed": {
+      "description": "Where its crawls start.",
+      "title": "Seed"
+    },
+    "settings": {
+      "description": "No project_id only: every common setting as {key, meaning, default}.",
+      "title": "Settings"
+    },
+    "status": {
+      "description": "draft, crawling, healthy or failing. On an error, the HTTP status code.",
+      "title": "Status"
+    }
+  },
+  "title": "ProjectOut",
+  "type": "object"
+}

Changed5 schema fields changedOct 6, 2026

addedInput schema / properties / config / description

Added value: +"Settings to change, e.g. {\"max_pages\": 200}; keys not given keep their values. Omit to leave them all."

addedInput schema / properties / name / description
```
Added value: +"A new name; omit to leave it."
```

addedInput schema / properties / project_id / description

Added value: +"The project's id, as list_projects or create_project returns it."

changedInput schema / properties / schedule / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "manual",
+      "hourly",
+      "daily",
+      "weekly"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / schedule / description
```
Added value: +"A new schedule; omit to leave it."
```

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 cover the safety profile (destructiveHint=true, idempotentHint=false), and the description adds meaningful behavior beyond them: partial-merge semantics ('only what you pass changes... config={"max_pages": 200} leaves every other setting alone'), schedule='manual' stopping runs, replaced values not being versioned, markdown-affecting keys resetting the baseline, and the write-access/'read_only' refusal.

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?

It is long, but dense and well-labeled with 'Inputs:', 'Effect:', and the closing access note, all front-loaded around the modify semantics. Almost every sentence carries non-obvious information, with only minor overlap with the schema's own parameter descriptions.

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 destructive, non-idempotent mutation tool with an output schema, the description covers prerequisites (get_project), side effects (baseline reset, unversioned replacement), permissions and error code, and follow-up actions. Nothing an agent needs before invoking it 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 the baseline is 3, but the description goes beyond the schema by explaining that config is a shallow key-level merge, that webhook_url="" disables the webhook, that schedule='manual' stops runs, and how test_webhook is sequenced after changes. Useful additions, though project_id's sourcing merely restates 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+resource ('Change a project's name, schedule or settings, its webhook among them') and explicitly distinguishes siblings: create_project for another site, get_project for reading values, start_run to crawl. An agent can route to this tool without opening the 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?

Explicit sequencing: 'Call get_project first to see the current values,' 'to crawl with the new settings now, follow with start_run,' and 'to watch another site use create_project.' It also names the exclusion (a project's site cannot change) and where valid config keys come from.

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.