Skip to main content
Glama

baton

by io.github.vinsenzo83

baton_verify

독립 검증자가 넘어온 작업을 실제 실행·관측한 결과로 '서명된 검증 영수증(receipt)'을 발급한다. E2E 관측이 없으면 verified 불가(static-only). 영수증은 서버 서명이라 위조 불가 — baton_pass의 receipt 인자로 첨부하면 🕸️ 배지가 붙는다. 'AI 작업은 영수증 없이 믿지 마라.'

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYes검증 대상(기능/플로우)
api_keyNo검증자 계정 키 — 독립검증(🕸️)은 생산자와 다른 등록계정일 때만 인정. 없으면 자가증명(🔏). Authorization 헤더로도 자동첨부
capsuleNo검증하는 핸드오프 코드/해시
verifierNo검증한 사람/전문가 신원(예: 'TM-expert-15yr'). 그 분야 전문가가 검증해야 진짜 신뢰 — 영수증에 남는다
artifactsNo증거 아티팩트 다이제스트(trace·har·screenshot·log)
environmentNo재현 환경(os·runtime·commit 등)
e2e_evidenceNo실제 실행·관측 결과. VERIFIED에는 method와 evidence_refs가 필요하며 없으면 STATIC-ONLY로 안전하게 강등
static_checksNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • changedInput schema / properties / e2e_evidence / description
      Previous value: -"실제 실행·관측 결과(HTTP 상태·DB delta·출력)"New value: +"실제 실행·관측 결과. VERIFIED에는 method와 evidence_refs가 필요하며 없으면 STATIC-ONLY로 안전하게 강등"
    • addedInput schema / properties / e2e_evidence / items / properties / evidence_refs
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / e2e_evidence / items / properties / method
      Added value: +{
+  "enum": [
+    "http",
+    "db-delta",
+    "command",
+    "browser",
+    "artifact",
+    "manual"
+  ],
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / api_key
      Added value: +{
+  "description": "검증자 계정 키 — 독립검증(🕸️)은 생산자와 다른 등록계정일 때만 인정. 없으면 자가증명(🔏). Authorization 헤더로도 자동첨부",
+  "type": "string"
+}
    • addedInput schema / properties / verifier
      Added value: +{
+  "description": "검증한 사람/전문가 신원(예: 'TM-expert-15yr'). 그 분야 전문가가 검증해야 진짜 신뢰 — 영수증에 남는다",
+  "type": "string"
+}
  3. Changed4 schema fields changed
    • addedInput schema / properties / artifacts
      Added value: +{
+  "description": "증거 아티팩트 다이제스트(trace·har·screenshot·log)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / capsule
      Added value: +{
+  "description": "검증하는 핸드오프 코드/해시",
+  "type": "string"
+}
    • addedInput schema / properties / environment
      Added value: +{
+  "additionalProperties": {},
+  "description": "재현 환경(os·runtime·commit 등)",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • addedInput schema / properties / target / description
      Added value: +"검증 대상(기능/플로우)"
  4. First observed

TDQS

B3.3/5.0
Behavior3/5

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

Without annotations, the description carries the burden. It explains that the receipt is server-signed and cannot be forged, and that without E2E evidence it's static-only. However, it does not disclose potential side effects or authorization requirements.

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?

The description is concise at three sentences, but it is in a single paragraph without clear structure. It effectively conveys the core purpose and caveats.

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

Completeness2/5

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

Given the tool has 8 parameters, nested objects, and no output schema or annotations, the description is too brief. It does not cover return values, error scenarios, or detailed usage steps, leaving gaps for complex use cases.

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 (88%), and the description adds minimal parameter-specific insight. The description does not elaborate on parameters beyond what the schema provides, so a baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states that the tool issues a signed verification receipt after independent verification, which distinguishes it from other baton tools. However, it could more explicitly differentiate from sibling tools like baton_verify_plan.

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

Usage Guidelines3/5

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

The description mentions that E2E observation is required for verification and that the receipt can be used with baton_pass, providing some usage context. However, it lacks explicit when-not-to-use guidance or comparison with alternatives.

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.

TDQS

C2.9/5.0
Disambiguation4/5

Most tools have distinct purposes due to detailed descriptions, but some potential overlaps exist (e.g., baton_revoke, baton_close_room, baton_leave). The complex domain is well-differentiated overall.

Naming Consistency3/5

The baton_ and spider_ prefixes provide consistency, but within baton_ there is a mix of verb-only, noun, and verb_noun patterns (e.g., baton_approve vs baton_account). Not fully predictable.

Tool Count2/5

With 45 tools, the server is very large and may overwhelm agents. While the domain is complex, many tools could potentially be consolidated, making the count excessive.

Completeness4/5

The tool surface covers account, room, handoff, verification, cost, memory, hub, task, and spider domains thoroughly. Minor gaps exist (e.g., no explicit tool to list rooms), but core workflows are well-supported.

Resources