Eclipse Aperture MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ECLIPSE_APERTURE_STATE | No | Override the state file path (default is data/state.json) |
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 |
|---|---|
| capability_probeA | Return Aperture's capability matrix from the STATIC declaration fixture (dated, [verify]-flagged): per-capability modes for an eligible professional Instagram account per spec SS9. NO live Graph API call is made in v0.1. Pass simulate_probe_failure=true to exercise the family downgrade rule: write modes collapse to prep, own-engagement to COMMUNITY_PREP. |
| variant_buildA | Build one native Instagram variant (feed 4:5 | carousel narrative order | reel 9:16 | story 9:16) from a canonical content package: geometry, caption, the working link path (profile link / Story sticker — caption links are not clickable), platform AI-media label, classified diff vs canonical, and the variant's hash. Formalization only — nothing is posted. |
| preview_packB | The exact native preview for a built variant — rendered geometry/caption/link path/safe zones — plus its diffs and the hashes an approval would bind. |
| 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 4 tools
Each tool targets a distinct stage: capability probing, variant construction, previewing, and receipt listing. There is minor overlap because variant_build and preview_pack both surface diffs and hashes, which could make an agent pause over which output is authoritative.
Names are consistently snake_case and mostly follow an object_action pattern: capability_probe, variant_build, receipt_list. preview_pack is slightly less natural but still readable and within the same convention.
Four tools is well-scoped for this narrow v0.1 formalization workflow. Each tool represents a distinct step and none appears redundant.
The surface covers probing, building, previewing, and listing receipts, but there is no exposed tool for managing canonical content packages or recording an approval/receipt action. The mention that previews expose hashes an approval would bind highlights a notable lifecycle gap.