sync: ignore keboola.mcp-server-tool workspace records like keboola.sandboxes — and manifest `ignoredComponents` is never read

[DasaDama]

Summary

Two related gaps, one small and one that leaves users with no safe option:

1. keboola.mcp-server-tool workspace records get pulled into sync trees, where they are pure noise: they carry no configuration at all. They belong on ALWAYS_IGNORED_COMPONENTS for exactly the reason keboola.sandboxes is there — "managed through separate APIs and have volatile internal state".
2. The manifest's ignoredComponents field is dead code. It is declared in the schema (sync/manifest.py:156) but no sync path reads it — pull, push and diff consult only the hardcoded ALWAYS_IGNORED_COMPONENTS (services/sync_service.py:492, :718, :1246). So a repo cannot decide for itself what to exclude, and has to wait for the constant to change upstream.

What these configs look like

One per project, created by the MCP server when it opens a workspace. The whole config body is empty:

version: 2
name: mcp-workspace-1e0a1688
_keboola:
  component_id: keboola.mcp-server-tool
  config_id: 01kya4jgtb39re9anfvnvc2ne7

config detail reports configuration: {}. In our repo that is 14 of them across 21 managed projects — one in every project that has been queried through the Keboola MCP server — and a new one appears whenever the MCP server touches a project that did not have one yet. They land in commits, in review diffs, and in sync diff output as + NEW keboola.mcp-server-tool/mcp-workspace-…, forever.

Why users cannot work around it safely today

The obvious workaround — stop tracking them in git — arms a production deletion, because the manifest still holds the entry while the directory is gone. Verified on a throwaway copy of a real sync tree (v0.59.0):

$ rm -rf <tree>/main/other/keboola.mcp-server-tool
$ kbagent sync push --project <alias> -d <tree> --dry-run
Dry run -- no changes applied:
  DELETED keboola.mcp-server-tool/mcp-workspace-98305b1c

Would create 0, update 0, delete 1

Same output on v0.90.1. That is the documented delete-dir-then-push GitOps semantics working as intended — but it means "I don't want this component in my repo" and "I don't want it deleted in production" are currently mutually exclusive. .gitignore alone does not help: the next sync pull re-materializes the files, so they come back as untracked noise on every pull.

Editing .keboola/manifest.json by hand to drop the entries is the other option, and #466 already established that manifest surgery should not be the answer.

Suggested fix

1. Add keboola.mcp-server-tool to ALWAYS_IGNORED_COMPONENTS (constants.py:652-656), next to keboola.sandboxes — same category, same rationale.
2. Honor manifest.ignoredComponents in the pull/push/diff loops (union it with ALWAYS_IGNORED_COMPONENTS at the three call sites above), so a repo can exclude volatile components without an upstream release. Alternatively drop the field from the schema, so it stops looking like a supported knob.

For an already-polluted tree it would also help if entries for a newly ignored component were dropped from the manifest on the next pull, rather than left behind to be reported as DELETED by the next push.

Environment

Reproduced on kbagent v0.90.1 (freshly installed via install.sh after the #424 rename, as advised on #466); first noticed on v0.59.0. Cited line numbers are from main @ v0.90.1. Repo of ~20 production projects on one stack, config-only sync trees (sync pull --all-projects --no-jobs --no-storage).

[padak]

Thank you @DasaDama — and thanks for including the reproduction of the polluted tree, which is what made the cleanup path designable rather than guessable.

Fixed in #691: keboola.mcp-server-tool now sits next to keboola.sandboxes on ALWAYS_IGNORED_COMPONENTS, and the manifest's ignoredComponents field — declared in the schema and, as you found, read by nothing — is now live and unions with the hardcoded set across pull, diff and push. sync pull drops manifest entries and local directories for a newly-ignored component under a new action ignored, deliberately distinct from removed.

One correction to the framing, verified by test: a stale manifest entry does not classify as DELETED once the remote side is filtered — compute_changeset derives deletes from remote keys, so it classifies as added while keeping its config id, meaning every push would CREATE a duplicate. Same fix either way, but worth recording since the failure mode is different from the one described.

Merged to main and queued for v0.91.0.