How to Connect GitHub Copilot in VS Code to Social Media With MCP

Connect GitHub Copilot in VS Code to social media by adding Groniz as a remote MCP server of type http. Put it either in workspace .vscode/mcp.json or in your user profile. Use https://mcp.groniz.com/mcp, prefer OAuth when available, and verify the server before trusting it. Enable only the tools the task needs.

The input should already be approved, such as a signed-off release note with cleared media. Copilot can inspect destination requirements and form the tool call. A person keeps control of facts, rights, disclosures, destination, final payload, and delivery time. Review the complete write before invocation, submit it once, and capture the returned post ID. If the result is uncertain, reconcile it before retrying.

Turn an approved repository asset into a controlled delivery

VS Code often puts the code and its surrounding issue, changelog, or draft copy in one place. That context is useful, but it can blur the line between material the agent may read and material the company has approved for publication.

Create a small handoff packet before configuring the write path:

Canonical source file or URL:
Approved commit, tag, or version:
Facts and links checked by:
Rights and consent checked by:
Disclosure decision:
Approved copy or adaptation constraints:
Approved media:
Allowed account and delivery window:

Keep unreleased changes, credentials, internal issue comments, and unapproved claims outside the packet. Creation, research, recording, editing, approval, and rights or disclosure checks stay outside Groniz. GitHub Copilot can prepare a proposal from the packet, but a person must approve the destination-specific result.

The release-notes-to-LinkedIn workflow shows one way to preserve the source boundary. The same principle applies here even though the client and delivery route differ.

Choose workspace or profile scope

VS Code’s official MCP server documentation supports workspace configuration in .vscode/mcp.json and user-level configuration in a profile.

A committed workspace server definition travels with the project. The team can review the intended integration, but source control creates a hard boundary: never place a real API key, bearer token, or key-bearing endpoint URL in committed configuration. Contributors should be able to inspect the server definition without receiving another operator's publishing credential.

A profile-scoped server stays with the user's VS Code setup and can apply across workspaces. That fits cases where publishing authority belongs to an individual operator rather than the repository. The server may also be available while unrelated projects are open, so tool toggles and write approval still matter.

Use this scope decision table:

Question	Workspace .vscode/mcp.json	User profile
Who owns the definition?	Project maintainers	Individual operator
Where may it appear?	Repository and collaborators’ workspaces	That user’s configured profiles
Main credential risk	Secret committed or shared with the project	Personal connection used in the wrong workspace
Required control	Share only a secret-free definition	Keep tools narrow and verify the active workspace

Scope decides where VS Code loads the server. It does not decide whether any specific post is approved.

Configure the remote HTTP server

The Groniz remote MCP endpoint is:

https://mcp.groniz.com/mcp

VS Code identifies a remote server with type http. This illustrative skeleton shows only the non-secret part of the workspace decision; consult the current official documentation for the exact supported authentication flow in your VS Code version:

{
  "servers": {
    "groniz": {
      "type": "http",
      "url": "https://mcp.groniz.com/mcp"
    }
  }
}

Prefer OAuth when VS Code offers it for the server. Groniz MCP also supports an Authorization: Bearer YOUR_API_KEY header or a key embedded in the URL. If the current environment requires a key, use VS Code’s documented protected-input or secret mechanism instead of hardcoding it. The issuance location is Groniz Connectors API keys. Never put a real value in .vscode/mcp.json, a prompt, screenshot, example, or run log.

For the relationship between the server, publishing layer, and provider, read social media MCP servers. The client-by-client setup guide explains why copying another agent's configuration may lose VS Code's scope and trust controls.

Review server trust and tool access

VS Code requires the user to trust an MCP server before use. Verify the displayed server identity and endpoint, then make a deliberate trust decision. Trust permits VS Code to load the server’s capabilities; it is not approval to publish.

VS Code also lets users toggle specific tools. Keep the available surface matched to the task. Listing integrations and publishing to an account have very different consequences. Enable the write only when the approved delivery needs it, and keep the final invocation reviewable.

This configuration-scope and server-trust checklist is the original setup asset:

### VS Code MCP configuration and trust

- [ ] The approved source packet has a stable version.
- [ ] Workspace or profile scope is explicitly selected.
- [ ] A workspace definition contains no real credential or key-bearing URL.
- [ ] The server type is remote `http`.
- [ ] The endpoint is exactly `https://mcp.groniz.com/mcp`.
- [ ] OAuth is preferred when available.
- [ ] The operator verified the server before trusting it.
- [ ] Only required tools are enabled.
- [ ] Social writes retain a separate review and approval.
- [ ] The active workspace and acting account are recorded.

Server trust is durable, while content approval applies to a specific payload. A reviewer approves this payload for this account and time, not every future request made through the server. The human approval policy guide provides a template for that distinction.

Inspect the live destination requirements

Once the connection is trusted, have Copilot begin with the discovered read operations:

inspect current server tools
→ list connected integrations
→ select an explicit profile, Page, channel, or community
→ inspect its live required settings
→ prepare the destination payload

Record a human-readable account label beside the integration reference. A repository named after a company does not prove that the similarly named social Page is the right destination. If more than one connection is plausible, ask a person to choose.

Groniz handles provider OAuth, per-platform formatting, and delivery to 32+ networks. It does not offer identical fields, media, analytics, or scheduling across providers. Do not hardcode provider-specific Groniz fields in the repository or infer them from another network’s example. The selected integration’s live settings are authoritative.

If the approved asset includes media, upload it before the post is created or scheduled. Verify the upload result and keep its returned reference with the right destination. Include media order and supported destination settings in the final review.

Review the exact write in VS Code

Have Copilot present the complete proposal without credentials:

Source version:
Network and exact connected account:
Final text, links, and disclosure:
Uploaded media references and order:
Live destination settings:
Publish now or schedule:
Local time and timezone:
Exact timestamp with offset:
Publishing operation to invoke:

The reviewer checks facts, rights, disclosure, destination, payload, media, and timing together. If Copilot changes any item after approval, cancel the write and obtain another decision. A merged pull request or approved release does not automatically approve every social adaptation of it.

Copilot reads and assembles the operator's packet. Groniz formats and delivers it through the selected integration. The account owner decides whether the exact post may go public.

Verify accepted delivery before closing the task

Submit once. Record the submission time, integration, source version, response state, requested schedule, and returned post or scheduled-record ID. For immediate publication, inspect the supported state and public destination when a public reference is available. For a schedule, confirm the stored account, payload, time, timezone, and offset.

Do not turn a timeout into an automatic second call. VS Code or the agent may lose the response after the server has accepted the request. Inspect the available records and intended social account for the original delivery. Keep the state as unknown until evidence resolves it, and escalate if it remains ambiguous. Retry only after non-delivery is established; re-approve any corrected payload or time.

Archive the response with the approved packet to make the first delivery auditable. Reach, engagement, leads, sales, and revenue are not part of that evidence.

Once the approved repository asset and VS Code trust checklist are complete, connect the reviewed Copilot workflow through Groniz Connectors.