copying-endpoints-across-projects

You need the endpoint's name and the source project.

• If the user gave a name, use it. If they gave a fuzzy description, call endpoints-get-all in the source project and match on name/description.
• If the user didn't say which project the endpoint lives in, ask — don't assume the active MCP project is the source. Copying out of the wrong source is the most common foot-gun.
• Confirm the active project is the source (call project-get with no id to see the active project) before reading.

Call endpoint-get with the source name. Capture everything you'll need to recreate it:

• name
• query (the whole HogQL/insight query definition — including any declared variables / code_names)
• description
• data_freshness_seconds
• is_materialized (source state — see step 5 for why you usually don't copy this as-is)
• tags

Present a short summary to the user before copying: what the query returns, its variables, its freshness setting, and whether the source is materialised.

Cross-project: confirm the target project belongs to the same org and the user has editor access there. The copy will be created in whatever project is active at endpoint-create time, so plan to switch the active project to the target between step 2 and step 6.

Same-project duplicate: the new endpoint needs a different name — names are unique within a project and the URL path (/api/projects/{team_id}/endpoints/{name}/run) depends on it. Agree a new name with the user.

Either way, run endpoints-get-all in the target project and check whether the intended name already exists. If it does, stop and ask: creating over an existing name is not a safe silent action. Get the name right up front — it's baked into the caller URL and not trivially renameable later.

• Cross-project, same purpose: keep the same name so caller code ports unchanged.
• Same-project or "copy to iterate": pick a clearly-derived new name (e.g. weekly_active_users_v2, weekly_active_users_staging). Snake_case, URL-safe, starts with a letter, max 128 chars.

Default to is_materialized: false on the copy, even when the source is materialised. Rationale mirrors the safe default in copying-flags-across-projects (land disabled): materialisation costs recompute/storage on a cadence, and a freshly-copied endpoint has no proven traffic in the target yet. Ship it unmaterialised, confirm it's actually called, then enable materialisation later once usage justifies the cost.

Override to is_materialized: true only if the user explicitly wants the copy materialised from day one (e.g. a like-for-like production promotion of a high-traffic endpoint). Note the caveats from creating-an-endpoint: queries with cohort breakdowns or compare mode, and insight kinds other than Trends/Lifecycle/Retention (e.g. Funnels), are not materialisable — endpoint-create will simply create them unmaterialised regardless.

Carry data_freshness_seconds over unchanged unless the user wants different freshness in the target (remember it doubles as the materialisation refresh cadence).

With the target project active, call endpoint-create with:

• name — from step 4
• query — the source query captured in step 2, verbatim (this carries the variables/code_names)
• description — from source (optionally note it's a copy)
• data_freshness_seconds — from source unless the user changed it
• is_materialized — from step 5 (default false)
• tags — from source if the user wants them; drop tags that are meaningless in the target project

Call endpoint-run on the new endpoint with a representative variables payload and confirm the response shape matches the source. For a cross-project promotion, sanity-check that the underlying events/properties the query references actually exist in the target project — a query that's valid in staging can return empty or error in a project with different taxonomy. If the copy is HogQL and callers rely on offset pagination, note that offset on endpoint-run is only supported for HogQL endpoints (not insight endpoints).

Tell the user: the new endpoint's name and project, its materialisation state, its freshness setting, and the result of the verification run. If you switched the active project to do the copy, say which project is active now so they aren't surprised on their next call.