Connect Claude to Segment

Return the workspace this token belongs to, with its id, name and slug. Segment has no endpoint that lists workspaces - a Public API token opens exactly one, and this is how you find out which. Call it first when you do not know what the connection reaches, and treat it as the connection test: it costs nothing, needs no arguments, and a token that fails here is wrong rather than under-scoped.

List the sources in the workspace - the websites, apps, servers and cloud integrations that send data in - with each one's id, name, slug, enabled state and metadata. This is the usual second call after get_workspace and the way to find the source id every other source operation takes. It returns configuration, not events: nothing here reads what a source has collected.

Fetch one source by id, with its full settings, its metadata and the id of the tracking plan connected to it. Ids come from list_sources. Use list_connected_destinations to see where this source's data goes.

List every destination in the workspace - the tools data is forwarded to - with each one's id, name, enabled state and the source it is attached to. Use it to answer "where does our data end up" across the whole workspace; use list_connected_destinations when the question is about one source. Destination settings frequently contain the API keys of other products, so treat what comes back as configuration that names secrets even where their values are masked.

Fetch one destination by id, with its full settings and the source it is attached to. Ids come from list_destinations or from list_connected_destinations. This is the call that explains why a destination is or is not receiving something.

List the tracking plans in the workspace with their ids, names and types. A tracking plan is the contract for what events a source is allowed to send and what shape they take, so this is where a question about expected event schemas starts. Requires the Protocols feature on the workspace - without it this fails whatever the token's scopes say, which reads as a permission error and is not one.

Return the rules of one tracking plan: the JSON Schema for every event it governs, with each event's name, type and property definitions. This is the schema surface an agent actually wants - it says what a valid event looks like without reading a single real event. Ids come from list_tracking_plans. Segment rate-limits this route harder than the rest of the Public API, at 200 requests a minute, so page through it rather than looping it tightly.

List the warehouses the workspace loads into, with each one's id, metadata, enabled state and settings. Use it to find out where Segment data lands for analysis - the answer is usually the same database a BigQuery, Snowflake or Postgres connection on this gateway already reaches, and this is how you confirm it is the same one.

List the destinations one source is connected to. This is the per-source view of the data flow, and the call to make when the question is "where does this website's data go". Note the asymmetry: the route is named connected-destinations and the payload comes back under `destinations`, which is Segment's shape rather than a mistake here. Source ids come from list_sources.

List the functions in the workspace - the custom code Segment runs to shape data on the way in or out - with each one's id, display name, description and code preview. IMPORTANT: `resource_type` is required and there is no call that returns all of them at once. Segment lists functions one kind at a time, so ask for SOURCE, DESTINATION, INSERT_SOURCE, INSERT_DESTINATION or INSERT_TRANSFORMATION separately and combine the answers yourself. Omitting it returns an error that reads like a bad request rather than a missing filter. Requires the Functions feature on the workspace.