Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Proposal: give Obol agents controlled X publishing via MCP

Aperta
  • Qualcosa non va?
#698 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
go, helm, kubernetes
Ambito
ai, api, backend-api-design, cloud, devops

Direzione di ricerca

Inizia tracciando gli entry point di obol agent init e obol agent sync, quindi esamina la riconciliazione di Agent e i pattern esistenti dei server MCP x402. L’issue non indica file, quindi mappa questi flussi prima dell’implementazione; il lavoro è completo quando l’account X condiviso è autenticato senza credenziali dell’agent-pod, la configurazione MCP sopravvive a sync e alla riconciliazione, e vengono testati config, il wiring di Secret, policy e il comportamento di audit.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Go
Stelle
11
Fork
1
Merge medio
1h 20m
PR unite (30g)
39

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ObolNetwork/obol-stack

Tutte le issue di ObolNetwork/obol-stack

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.