Eclipse Social Core MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ECLIPSE_SOCIAL_CORE_STATE | No | Override the path where state persists. By default, state persists in data/state.json beside the server. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| account_setA | Register/update an authorized account: platform, adapter, owner, role, declared capability modes (capability -> mode), and the latest capability probe {status: ok|failed, at, terms_version}. A FAILED probe downgrades effective modes automatically (write modes collapse to prep; reads flagged). Evaluation only — no platform is contacted, no credentials are held. |
| account_inventoryA | All registered accounts with declared + effective mode matrices, last probe, and kill-switch state. No credential values exist in this system. |
| content_ingestA | Ingest a canonical content object (SS3.1): masters + provenance, copy, claims WITH sources, rights per asset, accessibility assets, disclosure record, intended/prohibited surfaces, schedule. Validates and issues the SHA-256 content hash; re-ingesting changed content bumps the version. Missing rights/claims-sources/alt-text are named blockers. |
| content_getC | One canonical content record in full, hash + approval state included. |
| adapt_previewC | Build one native variant for an adapter profile (aperture_feed, aperture_reel, aperture_story, prism_shorts, zephyr, wire): media geometry, copy under the surface's limit, the surface's working link placement, platform-required disclosure labels, element order — plus the classified adaptation diff. The variant is hash-bound at build. |
| adaptation_diffC | The classified diff for a built variant (MEDIA_CROP, TEXT_REWRITE, LINK_PLACEMENT, ORDER, DISCLOSURE, METADATA, FORMAT_OMISSION, ...). Substantive changes — numbers, claims, CTA — are flagged, never silent. |
| variant_reviseA | Revise a variant's copy/hashtags/schedule/destination/link/disclosures/order/media. HASH LAW: the hash recomputes; an approval bound to the old hash is invalidated and the variant returns to review. |
| approval_packC | The review artifact (SS3.2 tool 6): canonical item + every native variant + diffs + destination/account + schedule. This is the object the owner approves. |
| approve_variantC | Record the owner's approval of one variant, bound to the exact canonical hash and exact variant hash. |
| approval_checkB | Verify a variant's approval is still valid: recompute the hash from current fields and compare with the approved hash. Any post-approval change = invalid. |
| policy_checkB | Engagement policy evaluator — the house playbook as data (SS5). action: like | comment | report_stop | reset. Enforces week-1 caps (15 likes / 5 comments per day) and week-2+ caps (30/10), the 2-likes-per-target cap, no links / no self-promo / no hashtag stuffing / <=1 emoji in comments, no duplicate comments, and stop-signal finality. EVERY check is receipted, ALLOW and DENY alike. |
| engagement_logB | Append one executed or owner-completed engagement action to the append-only log (timestamp, account, adapter/mode, target, action, full comment text, why, result, cap context, stop state). |
| engagement_reportC | Daily-report view over the engagement log: every action, totals vs the week's caps, stop state. |
| adapter_kill_switchB | Independently disable one capability scope: family | adapter | account. Write capabilities freeze first; drafts and receipts remain readable. |
| receipt_listB | The append-only, hash-chained receipt ledger, with chain verification. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools map to clearly distinct resource-action pairs, but the adaptation and approval cluster (adapt_preview, adaptation_diff, variant_revise, approval_pack, approve_variant, approval_check) has subtle boundaries that rely heavily on the descriptions. An agent can tell them apart, but several are close enough that misselection is plausible without careful reading.
All names use snake_case, but the structural convention is mixed: noun_verb (content_ingest, content_get, variant_revise, account_set, policy_check), verb_noun (adapt_preview, approve_variant), and noun_noun compounds (approval_pack, adaptation_diff, engagement_report, receipt_list). It remains readable, but there is no single predictable pattern.
Fifteen tools fit a multi-stage governance domain involving content lifecycle, adaptation, approval, accounts, engagement policy, kill switches, and receipts. Each tool maps to a distinct operation in that pipeline, and none appears to be filler.
Core ingest/get, adaptation, approval, account, policy, and receipt operations are covered, but there is no list/search capability for canonical content or variants and no direct variant_get. Agents must know content or variant IDs out-of-band, which is a notable discovery gap for an otherwise lifecycle-oriented toolset.