Checkup

What Checkup reads

Checkup looks at what this workspace currently holds — the tools cached from each connected source, and the tools each server lists — and reports what is wrong with them. It reads state, not code: none of this exists in a source tree, so nothing that runs before a deployment can tell you about it.

It is readable by anybody signed in, and it returns nothing the Sources list does not already show: labels, tool names, behaviour grades and counts. No schemas, no credentials, no endpoints.

The top of the page counts the tools offered, the sources, the servers, how many findings must be fixed, and how many are worth knowing. Below that are two lists: each source with how many of its tools are enabled and how its tools are graded, and each server with its tool count and its behaviour ceiling.

Two kinds of finding

The distinction the page is built around is whose problem a finding is.

Must fix is something that cannot work. A tool with no name that nothing can call. A tool with no input schema, so a caller cannot know what to send. A schema shape the database refuses. A server listing tools no source offers any more. Two sources sharing a tool-name prefix, so a call lands on whichever is found first.

Worth knowing is something that works and is probably not what anybody meant. A tool with no description, which leaves a model guessing when it picks. A tool that declares neither readOnlyHint nor destructiveHint, so it classifies as unknown — which a ceiling treats as a delete and refuses. A server with no behaviour ceiling, where every writing tool it lists goes through.

Gradings you did not write

Two findings are about a provider’s own grading rather than anything Inline did.

If a source grades almost all of its writes at one severity, a ceiling between read and that severity refuses every write the source has, and a ceiling at it allows all of them. There is no middle setting until somebody overrides some of those tools. Checkup says so, with the counts, because the alternative is a ceiling that looks meaningful and is not.

The sharper version of the same problem: a source that grades several tools as delete and none as update. Providers commonly use MCP’s destructiveHint to mean “not read-only” rather than “destroys data”, so a ceiling of update there may refuse edits you meant to allow. The advice is to read those tools and override the ones that only modify.

A third, quieter note appears when a server lists tools its own ceiling removes. An agent is never offered them — the ceiling filters the tool list rather than refusing at call time — so only the server’s own list still says otherwise. The usual cause is drift: a provider re-graded a tool under a ceiling that was already set.

What to do with it

Most findings point at one place. A missing description, a missing annotation or a wrong grade is fixed on the source, in Sources — by overriding the behaviour, or by switching off a tool nobody should be offered. A stale listing or a missing ceiling is fixed on the server. Nothing on this page changes anything by itself; Check again re-reads once you have.

Checkup is worth running after connecting a source, after a provider updates its tool set, and before handing a server to somebody who will trust it. It answers what is wrong now. What happened is Activity, and what has to stop and wait for a person is rules and approvals.