feat(cobuild): add get_cobuild_status

[ludwigehlert-gif]

Why

Checking Cobuild required listing every project to get one key: ~15 MB GET /projects/ on a 4099-project instance, into the agent's context. count_projects uses the same endpoint.

What

One tool. get_cobuild_status(project_key="") takes one key from the root project folder (~3 KB, instance-wide key list as fallback), opens a conversation there, returns enabled, instance_name, probed_project_key. 0.6s measured. A refusal raises, naming its three possible causes.

Cost per call

• 1 permanent conversation, titled "Empty chat"
• visible to the probing identity alone, in its own Cobuild history
• removable by that identity in the Cobuild panel; the public API lacks that route
• 1 audit entry (cobuild-conversation-create); 0 LLM traces, 0 usage rows
• project deletion currently leaves it (open DSS PR)

Tool tested against 15.x.

Replacement

Landed: dataiku/dip#52514, merged into release/14.7 on 2026-09-14. Ships in 14.7.5; 15.0.2 only if the forward merge makes that cut — release/15.0, release/15.1 and master do not carry it yet.

GET /publicapi/cobuild/status → DSSClient.get_cobuild_status() → {"enabled": true} or {"enabled": false, "reason": str}. 200 either way, no parameters, no audit entry, read transaction, raw dict passthrough. Instance-level, any authenticated caller.

Swap: delete _any_project_key and the probe, call the endpoint, pass reason through, set readOnlyHint: True, move the tool to the read bucket, drop the probe's skill rule and test. project_key and probed_project_key disappear with it.

Two constraints on that swap:

• bin/run_mcp.py pins dataiku-api-client==14.7.2, which has no get_cobuild_status. Either bump that pin to 14.7.5 or call client._perform_json("GET", "/cobuild/status"), which reaches the same URL under the SDK's /dip/publicapi base on the current pin.
• Detect by call-and-catch, never by version number: a 15.0.1 instance 404s while 14.7.5 answers. Old DSS raises DataikuException: NotFound, an SDK below 14.7.5 raises AttributeError. Keep the probe as the fallback branch, or drop it and require 14.7.5+.

enabled scope: instance-and-user entitlement, nothing more. checkCobuildAccess denies when the auth context carries no associated user or profile (project- and global-scoped API keys, the source named in reason), for the restricted profiles (READER, EXPLORER, AI_CONSUMER, AI_ACCESS_USER, GOVERNANCE_MANAGER), and when AI services are off — admins included, since the admin bypass sits after that check. Otherwise the use flag is merged across the "All users" row and the caller's group rows.

use is independent of the AIML/CODE/SQL categories: an account allowed only ML returns enabled: true and is still refused per tool by CobuildToolExecutionService. So enabled: true means "may open Cobuild", not "may build this flow"; project permissions and the LLM backend stay unproven. The probe additionally proves READ_CONF, because createConversation runs checkReadAccess = READ_CONF + checkCanUseCobuild. Community edition stays outside the check.

No regression risk for the existing Cobuild tools. The same dip PR moved the controller's class mapping from /publicapi/projects/{projectKey}/cobuild to /publicapi and spelled the full path on each of its six endpoints; final URLs are unchanged, verified against the four Cobuild routes SDK 14.7.2 calls (conversations, .../messages, .../confirmation/{id}, .../question/{id}).

Per-project precheck, if ever wanted: GET /projects/{key}/variables (DSSProject.get_variables()) enforces the same READ_CONF, verified as 200 with a 29-byte payload. get_summary() covers any-access alone; /{key}/settings requires project ADMIN.

Tests

test_cobuild_status_probes_without_the_instance_project_list: root-folder path, empty-root fallback, zero-project error, refused probe. Plus the surface pin and capabilities doc (128 → 129 tools, Cobuild 6 → 7).

uv sync --locked, pre-commit, pytest 298 passed, cz check.

🤖 Generated with Claude Code