Cyan Eclipse Apply MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ECLIPSE_APPLY_STATE | No | Optional path to override where state persists. By default, state persists in `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 |
|---|---|
| ingest_resumeC | Parse a plain-text/markdown resume into a structured profile, verbatim — the parser structures, never embellishes. (Facade addition: the concept's tool list omitted profile loading.) |
| set_policyA | The owner grants the application scope in writing: target roles, salary floor, locations, remote, allowlist/blocklist, daily cap, approval threshold, expiry. Returns the grant text. Nothing applies outside it. |
| get_policyB | Current policy, pause state, today's submission count, submission mode. |
| search_jobsC | Pull REAL public JSON feeds (Greenhouse/Lever/Ashby/Workable boards) and cache normalized jobs. |
| match_jobsB | Score every cached job vs profile+policy with a fully explained rationale (title/skills/comp/location) and policy eligibility. |
| prepare_applicationA | Policy-check, then build a PREPARED application: tailored resume (verbatim facts, re-ordered) + verifiable diff. Policy failures return a recorded refusal with reasons. |
| approve_applicationA | Owner approves a prepared application. For Greenhouse jobs this builds + validates the submission payload and records a DRY-RUN submission receipt. For any other source it returns a structured APPROVED-AND-HELD response (held=true, transmitted=false, hold_reason, receipt_seq) — the application stays in 'approved' for owner review. v0.1 transmits NOTHING. |
| reject_applicationB | Owner rejects a prepared/approved application; the rejection is receipted. |
| list_receiptsB | The append-only, hash-chained receipts ledger: grants, prepares, approvals, refusals, dry-run submissions, pause/resume. |
| get_trackerC | Application states: prepared -> approved -> submitted_dry_run -> closed, plus refusal count. |
| pauseB | KILL SWITCH: pause everything instantly. Prepares and submissions stop; the pause is receipted. |
| resumeC | Owner lifts a pause. Receipted. |
| delete_my_dataB | Verified purge of profile, policy, applications, cached jobs and the receipts ledger. Requires confirm=true. |
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 13 tools
Each tool targets a distinct stage or control: search vs. match vs. prepare vs. approve/reject are clearly separated, and policy get/set, pause/resume, tracker vs. receipts are also easy to distinguish. No two tools appear to do the same thing, and the descriptions reinforce the boundaries.
Nearly all tools follow a consistent snake_case verb_noun pattern (search_jobs, prepare_application, set_policy). The global pause/resume actions omit an explicit noun, which is a minor but reasonable deviation.
With 13 tools, the set is well-scoped for a job-application workflow that includes search, matching, preparation, approval, receipts, policy, and safety controls. Each tool appears to earn its place, and the count is comfortably within the ideal range.
The core lifecycle is covered: search, match, prepare, approve/reject, track, receipt, policy, pause/resume, and data purge. Minor gaps remain, such as no standalone tool to view or update a profile after ingestion, and no explicit job-detail or cached-job listing tool.