Proposal: give Obol agents controlled X publishing via MCP

[bussyjd]

Summary

Give Obol Stack agents a controlled way to publish to X through a stack-managed MCP service, so the default agent and CRD-created sub-agents can promote their services without each pod holding raw X credentials.

Background

X now documents a hosted MCP endpoint, and Hermes supports MCP servers. The hosted X MCP is useful for authenticated X API access and read/discovery workflows, but the documented capability set appears focused on reads/search/bookmarks/trends/news/Articles rather than ordinary Post creation. X's REST API still exposes POST /2/tweets, and Hermes also documents an xurl-based X skill for posting.

The stack already has the pieces we need:

• Hermes runtime config generation for the master agent.
• Agent CRD provisioning for durable sub-agents.
• Per-agent Secret/env injection through hermes-env.
• Go MCP server patterns in the existing x402 MCP implementation.
• x402 and storefront flows that make agent self-promotion valuable.

Proposal

Add a stack-managed x-publisher MCP service that exposes a deliberately small publishing surface:

• whoami: return the authenticated X account identity.
• draft_post: produce/validate a post draft without publishing.
• publish_post: publish a text post after policy checks.
• reply_to_post: reply to an existing post after policy checks.
• delete_own_post: delete a post previously created by the service.

The service owns X OAuth credentials centrally and calls the X API on behalf of agents. Hermes agents only see the MCP tools.

Suggested Architecture

1. Add an operator command such as obol social x auth or obol x auth.

   • Performs OAuth for the selected X account.
   • Requests only the scopes needed for posting, for example tweet.read, tweet.write, users.read, and offline.access.
   • Stores refresh/access material in a Kubernetes Secret owned by the stack.

2. Add a Deployment/Service for x-publisher.

   • Runs in a dedicated namespace or the existing platform namespace.
   • Reads X credentials from the Secret.
   • Serves Streamable HTTP MCP internally.
   • Emits structured audit logs for every draft/publish/delete action.

3. Render the MCP server into Hermes configs.

   • Master Hermes config gets the MCP server during obol agent init / obol agent sync.
   • CRD Agent-rendered Hermes configs get the same MCP server by default, or behind a spec flag if we want opt-in.

   Example shape:

   mcp_servers:
    x_publisher:
    url: http://x-publisher.social.svc.cluster.local/mcp
    tools:
    include:
    - whoami
    - draft_post
    - publish_post
    - reply_to_post
    - delete_own_post
    resources: false
    prompts: false

4. Add policy gates before publishing.

   • Per-agent rate limits, for example posts/hour and posts/day.
   • Duplicate/repost suppression.
   • Character limit and URL/card validation.
   • Optional human approval mode: agents can draft freely, but publish_post requires operator approval.
   • Configurable account modes: one shared operator account, per-agent account, or disabled.

5. Add a self-promotion skill/profile guidance.

   • Teach agents to announce their available paid services with pricing and endpoint links.
   • Keep claims factual and derived from ServiceOffer/status metadata.
   • Never expose tokens, private endpoints, local hostnames, or raw bearer values.

MVP

A minimal shippable version could be:

• One shared X account.
• Text-only posts.
• draft_post, publish_post, and whoami.
• Default draft_only=true until the operator flips publish_enabled=true.
• Per-agent daily rate limit.
• Audit logs and unit tests around policy checks.

Open Questions

• Should publishing be enabled for every agent by default, or only for agents that opt in through spec.social.x.enabled?
• Should sub-agents be allowed to publish directly, or only submit drafts to the master agent/operator?
• Should X publishing be sold as a paid MCP tool too, or remain an internal operator capability?
• Do we want X's hosted MCP included for read/search workflows separately from this publishing service?

Acceptance Criteria

• An operator can authenticate one X account without copying credentials into agent pods.
• The default Hermes agent can call draft_post and publish_post through MCP.
• A CRD-created Hermes sub-agent can use the same MCP tools without direct X token access.
• Publishing actions are rate-limited and logged.
• obol agent sync and Agent reconciliation preserve the MCP configuration.
• Tests cover config rendering, Secret wiring, and publish policy behavior.

[bussyjd]

Live experiment note: I validated the lowest-friction interim path by installing the official xurl CLI into a running default Hermes agent and a running CRD-created Hermes agent via a Kubernetes runtime patch. Both pods can now resolve xurl from the Hermes container, and the existing Hermes social-media/xurl skill has the posting commands documented.

Current blocker for actual posting is X OAuth: no X app/profile is registered in those Hermes homes yet. Once an operator completes xurl auth apps add, xurl auth oauth2, and xurl auth default against the Hermes HOME, the agent should be able to use the bundled skill to post/reply/delete through X. This reinforces the proposal above: the durable product version should manage OAuth centrally instead of requiring ad hoc per-pod setup.