Pipeline review (`x`)

Outcome: Did not fully converge after 3 review round(s). The draft may still be useful — decide on each item below, then reply and re-run.

Draft PR: #17

Decisions needed (9)

1. Fact check failed — setup and research disagree (or research is missing the fact).

Where in the guide: #enroll-developer-account
Section anchor: #enroll-developer-account
What's wrong: The enrollment path lacks the exact required field labels and final submission-control label needed to complete it literally.
What would unblock it: Escalate for a human-verified console capture recording every required field label, its value source, and the final submission control.
Needs a fact in research.md (or drop the step that depends on it).

Current guide text for this section

### Enroll in the X Developer Platform {#enroll-developer-account}

1. Go to [console.x.com](https://console.x.com).
2. Sign in with the X account that will own the developer app.
3. If prompted, review and accept the Developer Agreement and Policy.
4. Provide the requested information about how your organization will use the API. Obtain the wording from the application or cloud security owner if needed.
5. Submit the enrollment using the submission control shown in the console.

Successful enrollment opens the **Developer Console** dashboard. Confirm that **New App** is visible.

<!-- screenshot: the Developer Console dashboard after enrollment, with New App visible and account identifiers excluded -->

Reply with one of:

Decision 1: verified — … (paste the exact button / field / nav labels)
Decision 1: drop this branch (remove the recovery/optional path until we can verify it)
Decision 1: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

2. Fact check failed — setup and research disagree (or research is missing the fact).

Where in the guide: #create-x-app
Section anchor: #create-x-app
What's wrong: The app-creation path lacks the exact form-field labels and create-control label.
What would unblock it: Capture the authenticated console and record the current app-name, description, use-case, and create-control labels.
Needs a fact in research.md (or drop the step that depends on it).

Current guide text for this section

### Create an X app {#create-x-app}

1. On the **Developer Console** dashboard, select **New App**.
2. Enter the app name.
3. Enter the description.
4. Enter the use case.

> Before you submit the form, open your organization's password manager or secure vault. X displays generated credentials once.

5. Submit the form using the create control shown in the console.

X creates the app and displays its credentials, including the **Bearer Token**.

<!-- screenshot: the new-app form showing the app name, description, and use-case fields, with organization details redacted if necessary -->

Reply with one of:

Decision 2: verified — … (paste the exact button / field / nav labels)
Decision 2: drop this branch (remove the recovery/optional path until we can verify it)
Decision 2: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

3. Fact check failed — setup and research disagree (or research is missing the fact).

Where in the guide: Prerequisites — API credits
What's wrong: The required credit-purchase path stops at the Developer Console without navigation, purchase controls, required inputs, or a successful-balance state.
What would unblock it: Capture the authenticated purchase workflow and document it after any enrollment required for console access.
Needs a fact in research.md (or drop the step that depends on it).

Reply with one of:

Decision 3: verified — … (paste the exact button / field / nav labels)
Decision 3: drop this branch (remove the recovery/optional path until we can verify it)
Decision 3: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

4. Fact check failed — setup and research disagree (or research is missing the fact).

Where in the guide: #copy-bearer-token
Section anchor: #copy-bearer-token
What's wrong: The first-connect recovery path does not explain how to reopen the app or identify the control that regenerates a missed Bearer Token.
What would unblock it: Capture the dashboard-to-app-to-Keys-and-tokens path and record the exact regeneration-control label.
Needs a fact in research.md (or drop the step that depends on it).

Current guide text for this section

### Copy the Bearer Token {#copy-bearer-token}

Copy **Bearer Token** from the generated credential view into your organization's password manager or secure vault before leaving the page.

> Regeneration invalidates the old token.

If you miss or lose the token, regenerate it in the app. Save and use only the newly generated value.

<!-- screenshot-exception: the only useful state contains a live secret; do not capture the credential value -->

Reply with one of:

Decision 4: verified — … (paste the exact button / field / nav labels)
Decision 4: drop this branch (remove the recovery/optional path until we can verify it)
Decision 4: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

5. Guide structure / formatting rule broken.

Where in the guide: {#add-server-in-speakeasy} catalog path step 2 — "find X using **Search MCP servers...**"
Section anchor: #add-server-in-speakeasy
What's wrong: The catalog search term X is a value the reader types but is rendered as plain prose instead of a code span.
What would unblock it: Change the step to name the typed query in backticks, e.g. find X using Search MCP servers..., matching the persona formatting rule and the Asana guide pattern.
Needs a clearer step in setup.md (the fact may already be in research).

Current guide text for this section

### Add the server in Speakeasy {#add-server-in-speakeasy}

1. In the Speakeasy AI Control Plane sidebar, under **Connect**, select **Sources**.
2. Select **Add Source**.

If X appears in the catalog:

1. Select **3rd-party server**.
2. On the **MCP Catalog** page, find X using **Search MCP servers...**.
3. Select **View** for X.
4. Select **Add**.
5. In the **Add to Project** dialog, select **Add to Project**.

If X does not appear in the catalog:

1. Select **Custom remote server**.
2. On **Add a custom remote MCP server**, paste `https://api.x.com/mcp` into **Remote MCP server URL**.
3. Select **Add server**.

Either path creates the hosted MCP Server and opens its **Overview** page.

<!-- screenshot: the Add Source menu or the X catalog entry, without credentials -->

Reply with one of:

Decision 5: verified — … (paste the exact button / field / nav labels)
Decision 5: drop this branch (remove the recovery/optional path until we can verify it)
Decision 5: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

6. A cold reader would get stuck — a click, field, or next step is not named clearly enough.

Where in the guide: #enroll-developer-account
Section anchor: #enroll-developer-account
What's wrong: The enrollment path omits the required field labels and final submission-control label, forcing a first-time administrator to guess.
What would unblock it: Obtain a human-verified console capture and record every required field label, its value source, and the final submission control.
Needs a fact in research.md (or drop the step that depends on it).

Current guide text for this section

### Enroll in the X Developer Platform {#enroll-developer-account}

1. Go to [console.x.com](https://console.x.com).
2. Sign in with the X account that will own the developer app.
3. If prompted, review and accept the Developer Agreement and Policy.
4. Provide the requested information about how your organization will use the API. Obtain the wording from the application or cloud security owner if needed.
5. Submit the enrollment using the submission control shown in the console.

Successful enrollment opens the **Developer Console** dashboard. Confirm that **New App** is visible.

<!-- screenshot: the Developer Console dashboard after enrollment, with New App visible and account identifiers excluded -->

Reply with one of:

Decision 6: verified — … (paste the exact button / field / nav labels)
Decision 6: drop this branch (remove the recovery/optional path until we can verify it)
Decision 6: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

7. A cold reader would get stuck — a click, field, or next step is not named clearly enough.

Where in the guide: #create-x-app
Section anchor: #create-x-app
What's wrong: The app-creation path omits the exact field labels and create-control label needed to complete the form literally.
What would unblock it: Obtain a human-verified console capture and document the app-name, description, and use-case field labels plus the create control.
Needs a fact in research.md (or drop the step that depends on it).

Current guide text for this section

### Create an X app {#create-x-app}

1. On the **Developer Console** dashboard, select **New App**.
2. Enter the app name.
3. Enter the description.
4. Enter the use case.

> Before you submit the form, open your organization's password manager or secure vault. X displays generated credentials once.

5. Submit the form using the create control shown in the console.

X creates the app and displays its credentials, including the **Bearer Token**.

<!-- screenshot: the new-app form showing the app name, description, and use-case fields, with organization details redacted if necessary -->

Reply with one of:

Decision 7: verified — … (paste the exact button / field / nav labels)
Decision 7: drop this branch (remove the recovery/optional path until we can verify it)
Decision 7: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

8. A cold reader would get stuck — a click, field, or next step is not named clearly enough.

Where in the guide: Prerequisites — API credits
What's wrong: A positive credit balance is required for the first connection, but the guide provides no navigation path or named control for purchasing credits.
What would unblock it: Capture the authenticated console workflow and document its navigation, purchase control, required inputs, and successful-balance state after enrollment.
Needs a fact in research.md (or drop the step that depends on it).

Reply with one of:

Decision 8: verified — … (paste the exact button / field / nav labels)
Decision 8: drop this branch (remove the recovery/optional path until we can verify it)
Decision 8: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

9. A cold reader would get stuck — a click, field, or next step is not named clearly enough.

Where in the guide: #copy-bearer-token — "regenerate it in the app"
Section anchor: #copy-bearer-token
What's wrong: The immediate recovery path for a missed one-time Bearer Token omits how to reopen the app and which control regenerates the token.
What would unblock it: Obtain a human-verified console capture and document the dashboard-to-app-to-Keys-and-tokens path and exact regeneration-control label.
Needs a fact in research.md (or drop the step that depends on it).

Current guide text for this section

### Copy the Bearer Token {#copy-bearer-token}

Copy **Bearer Token** from the generated credential view into your organization's password manager or secure vault before leaving the page.

> Regeneration invalidates the old token.

If you miss or lose the token, regenerate it in the app. Save and use only the newly generated value.

<!-- screenshot-exception: the only useful state contains a live secret; do not capture the credential value -->

Reply with one of:

Decision 9: verified — … (paste the exact button / field / nav labels)
Decision 9: drop this branch (remove the recovery/optional path until we can verify it)
Decision 9: hedge — … (keep a softer “if you see X, ask your admin” line instead of exact clicks)

Open questions (4)

Research could not prove these from public docs. Check the boxes by replying with answers, or say “unknown / omit”.

X's public Developer Console documentation does not publish the exact field labels or final submit-button label in the first-time developer enrollment flow.
X's public documentation says to enter an app name, description, and use case after clicking New App, but does not publish the exact field labels or the final create-button label.
X documents an existing app's Keys and tokens page but does not name the dashboard control or navigation path used to reopen that app.
Provider documentation cannot establish whether X is currently present in the Speakeasy MCP Catalog; the canonical add-source conditional must remain until the catalog is observed.

How to retry

Reply on this issue using the Decision N: … lines above (and answer open questions).
Re-add the guide:draft label. Distill reads the issue body and comments into pipeline notes.
If a factory draft PR already exists (guide/issue-<N>-*), the next run resumes on that branch and revises prior research/setup instead of starting blank.

Source: run-record.json

Pipeline review (x)

Decisions needed (9)

1. Fact check failed — setup and research disagree (or research is missing the fact).

2. Fact check failed — setup and research disagree (or research is missing the fact).

3. Fact check failed — setup and research disagree (or research is missing the fact).

4. Fact check failed — setup and research disagree (or research is missing the fact).

5. Guide structure / formatting rule broken.

6. A cold reader would get stuck — a click, field, or next step is not named clearly enough.

7. A cold reader would get stuck — a click, field, or next step is not named clearly enough.

8. A cold reader would get stuck — a click, field, or next step is not named clearly enough.

9. A cold reader would get stuck — a click, field, or next step is not named clearly enough.

Open questions (4)

How to retry

Pipeline review (`x`)

Uh oh!

guide for the X mcp server #15

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions