Skip to main content
Glama

baton

by io.github.vinsenzo83
OverviewDiscussionsAdmin

baton_pass

현재 작업을 BATON Snapshot v1로 봉인해 핸드오프 코드(BTN-H-…)를 발급한다. 본문은 코드-파생 키로 암호화(서버가 평문 못 봄), 시크릿 자동 마스킹. verify에 관측 증거(E2E)를 바로 넣으면 서버가 그 자리서 서명된 검증 영수증을 발급·첨부해 🕸️ 배지가 붙는다(verify를 따로 부를 필요 없음).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
verifyNo관측 증거를 바로 첨부 → 서버가 서명 영수증 발급(E2E 관측 있어야 verified). verify를 따로 안 불러도 됨
api_keyNo발급받은 API 키(없으면 Free 플랜 월 20개 한도)
receiptNobaton_verify로 이미 발급한 서명 영수증(독립 검증자가 준 경우)
one_timeNotrue=한 번만 수신 가능
snapshotYes이어서 일하는 데 필요한 것만 구조화(대화 전체 아님)
member_idNo방에 입장한 내 member_id — 주면 발급된 핸드오프 코드를 그 방에 자동 전송(받는 세션은 baton_inbox에서 바로 확인, 코드 복붙 불필요)
ttl_hoursNo
parent_codeNo이 핸드오프가 갱신하는 이전 핸드오프 코드 — 버전 체인 연결(baton_diff용)
verify_manifestNo(레거시) 원시 증거 매니페스트 — 서버가 재계산

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / verify / properties / e2e_evidence / items / properties / evidence_refs
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / verify / properties / e2e_evidence / items / properties / method
      Added value: +{
+  "enum": [
+    "http",
+    "db-delta",
+    "command",
+    "browser",
+    "artifact",
+    "manual"
+  ],
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / member_id / description
      Previous value: -"room에 입장한 내 member_id(자동 전송 발신자)"New value: +"방에 입장한 내 member_id — 주면 발급된 핸드오프 코드를 그 방에 자동 전송(받는 세션은 baton_inbox에서 바로 확인, 코드 복붙 불필요)"
    • removedInput schema / properties / room
      Removed value: -{
-  "description": "방 코드(BTN-R-…). 주면 핸드오프 코드를 이 방에 자동 전송 — 받는 세션은 baton_inbox에서 바로 확인(코드 복붙 불필요)",
-  "type": "string"
-}
  3. Changed4 schema fields changed
    • addedInput schema / properties / member_id
      Added value: +{
+  "description": "room에 입장한 내 member_id(자동 전송 발신자)",
+  "type": "string"
+}
    • changedInput schema / properties / receipt / description
      Previous value: -"baton_verify가 발급한 서명된 검증 영수증(첨부 시 🕸️ 배지)"New value: +"baton_verify로 이미 발급한 서명 영수증(독립 검증자가 준 경우)"
    • addedInput schema / properties / room
      Added value: +{
+  "description": "방 코드(BTN-R-…). 주면 핸드오프 코드를 이 방에 자동 전송 — 받는 세션은 baton_inbox에서 바로 확인(코드 복붙 불필요)",
+  "type": "string"
+}
    • addedInput schema / properties / verify
      Added value: +{
+  "description": "관측 증거를 바로 첨부 → 서버가 서명 영수증 발급(E2E 관측 있어야 verified). verify를 따로 안 불러도 됨",
+  "properties": {
+    "artifacts": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "e2e_evidence": {
+      "items": {
+        "properties": {
+          "claim": {
+            "type": "string"
+          },
+          "detail": {
+            "type": "string"
+          },
+          "observed": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "claim",
+          "observed",
+          "detail"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "environment": {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "static_checks": {
+      "items": {
+        "properties": {
+          "dim": {
+            "type": "string"
+          },
+          "evidence": {
+            "type": "string"
+          },
+          "passed": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "dim",
+          "passed",
+          "evidence"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "verifier": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  4. Changed2 schema fields changed
    • addedInput schema / properties / receipt
      Added value: +{
+  "description": "baton_verify가 발급한 서명된 검증 영수증(첨부 시 🕸️ 배지)"
+}
    • changedInput schema / properties / verify_manifest / description
      Previous value: -"baton_verify 결과(있으면 배지 부여)"New value: +"(레거시) 원시 증거 매니페스트 — 서버가 재계산"
  5. First observed

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses encryption (server cannot see plaintext), automatic secret masking, and immediate receipt issuance if e2e_evidence provided. Lacks details on destructiveness but adequately covers key behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single dense paragraph front-loaded with main action. No wasted words, though some technical details could be reorganized for clarity. Efficient for its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main workflow and key parameter interactions (verify, member_id, parent_code), but lacks output schema and does not describe return format or all parameter dependencies (e.g., one_time, ttl_hours). Incomplete for a tool with 9 parameters and nested objects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (89%) with good parameter descriptions. The tool description adds overall context and flow (e.g., verify parameter usage), but does not significantly enhance individual parameter meaning beyond what schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool seals current work into a BATON Snapshot v1 and issues a handoff code (BTN-H-...). It distinguishes from siblings like baton_verify by noting that passing e2e_evidence in verify parameter eliminates need for separate verify call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use: to create a handoff, and when to include e2e_evidence to avoid calling baton_verify separately. No explicit when-not-to-use, but context is clear from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All baton toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources