Twin Me Up
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TWINMEUP_HOME | No | Set this to move the twin's data directory. Everything lives in ~/.twinmeup by default. |
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 | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| twin_briefA | Call at the start of work in a workflow. Returns the principal's confirmed guidance, hard limits, your authority, stop conditions and how to report back. Embed and follow it. |
| twin_authoriseA | Call before any consequential action (sending, paying, committing, writing to live systems). 'allow' means an active grant covers it. 'ask' means stop, prepare a draft and request approval with twin_request_approval. |
| twin_request_approvalA | Call when twin_authorise says 'ask' and the work needs that action. Records one request the principal approves or declines in their own terminal. Do not act until twin_approval_status says approved; an approval covers one attempt unless they say more. |
| twin_approval_statusA | Whether the principal has approved, declined or not yet decided a request, and whether the approval is still unused. Poll this while you wait; it changes nothing. |
| twin_searchC | Find the principal's confirmed guidance relevant to a question within a workflow. |
| twin_review_queueB | Unconfirmed lessons to present to the principal for confirmation, revision or rejection. |
| twin_track_recordB | Evidence and stage for a workflow: confirmed learning, corrections, evaluation results, grants and the recommended next step. It recommends; only the principal promotes. |
| twin_next_questionsC | The most valuable unanswered questions about a recorded decision. Ask them, then amend. |
| twin_record_decisionB | Capture a real decision: situation, options, choice, reasons for rejected options, cues, what would change it and when to escalate. Returns follow-up questions. |
| twin_amend_decisionB | Merge the principal's answers to follow-up questions into a recorded decision. |
| twin_record_correctionA | Call whenever the principal edits, overrides or rejects your work. Captures both versions and the reason as learning material. |
| twin_propose_lessonA | Propose a lesson for the principal to confirm. It is never authoritative until confirmed. |
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 12 tools
Each tool targets a distinct step in the principal-agent workflow: brief vs search vs track_record differ by scope and timing; authorise, request_approval, and approval_status form a clear sequence; decision, correction, and lesson tools are clearly separated. Descriptions make intended use unambiguous.
All tools use the twin_ prefix and snake_case, which is highly consistent. However, the stems mix verb forms (authorise, search) with noun phrases (approval_status, review_queue, next_questions), so it falls short of a uniform verb_noun pattern.
12 tools is well within the ideal 3–15 range and each maps to a distinct governance function: briefing, authorisation, approvals, decisions, corrections, lessons, and tracking. No obvious redundant or trivial tools.
The surface covers the core lifecycle: briefing, authorisation, approval, decision recording/amendment, corrections, lessons, and tracking. Minor gaps exist, such as no explicit decision retrieval by ID or lesson confirmation tool, but these are largely handled by principal-side actions or search.