de en es ja ko ru zh

Bling-bag

Name: Bling-bag
Author: tjclaude88

by tjclaude88

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Bling Bag

봇에게 정체성을 부여하세요.

봇에게 이름이 있나요? 이제 성격, 외형, 그리고 배경 이야기를 부여할 차례입니다.

휠을 돌려 결과를 확인하거나 bling.json 파일에 직접 작성해 보세요.

npm version Glama

제공 기능

5개의 MCP 도구와 2개의 ID 풀:

WOW — Weird Office Workers (괴짜 사무직원들)

무작위로 괴짜 사무직원 봇을 생성합니다: 이름, 직함, 책상 설정, 습관, 커피 취향, 그리고 스크린샷용 공유 카드. 99/99 테스트 완료, 완전한 희귀도 엔진, 13개의 가중치 특성 풀.

Legends — 역사적 인물들

같은 엔진, 다른 세계관. 역사적 인물을 황당한 기업 역할로 생성합니다 — 적대적 인수합병 전문가 율리우스 카이사르, 연구실 안전 요주의 인물 마리 퀴리, 지역 관리자(프랑스 및 주변 지역) 나폴레옹.

roll_identity에 variant: "legends"를 전달하여 사용하세요. 기본값은 "wow"입니다.

Related MCP server: being-mcp-server

설치

사전 요구 사항

Node.js 20 이상
MCP 호환 클라이언트 (Claude Code, Claude Desktop, Codex, Cursor 등)

패키지 추가

npm install bling-bag

또는 설치 없이 즉시 실행 — MCP 클라이언트는 npx bling-bag을 통해 직접 실행할 수 있습니다(아래 클라이언트 설정 참조).

개발용 (소스 수정 시)

git clone https://github.com/tjclaude88/mcp-bling.git
cd mcp-bling
npm install
npm run build

dist/index.js에 실행 가능한 서버를 생성합니다.

MCP 클라이언트에 연결

이 서버는 stdio 전송을 사용합니다 — 클라이언트는 네트워크 포트가 아닌 자식 프로세스로 서버를 실행합니다.

Claude Code

Claude Code MCP 설정에 추가하세요(버전에 따라 위치가 다를 수 있음):

{
  "mcpServers": {
    "bling": {
      "command": "npx",
      "args": ["-y", "bling-bag"],
      "env": {
        "BLING_PATH": "/absolute/path/to/your/bling.json"
      }
    }
  }
}

npx -y bling-bag은 별도의 설치 단계 없이 최신 버전을 다운로드하고 실행합니다.

Claude Desktop

claude_desktop_config.json에 동일한 형식으로 추가:

{
  "mcpServers": {
    "bling": {
      "command": "npx",
      "args": ["-y", "bling-bag"],
      "env": {
        "BLING_PATH": "/absolute/path/to/your/bling.json"
      }
    }
  }
}

특정 버전 고정 (운영 환경 권장)

향후 릴리스가 자동으로 업데이트되는 것을 방지하려면 특정 버전을 고정하세요:

"args": ["-y", "bling-bag@0.1.0"]

개발 모드 호출 (로컬 클론에서)

리포지토리를 클론하고 dist/에서 직접 실행하려면 다음을 사용하세요:

"command": "node",
"args": ["/absolute/path/to/mcp-bling/dist/index.js"]

BLING_PATH가 설정되지 않은 경우, 서버는 작업 디렉토리에서 ./bling.json을 찾습니다.

설정 우선순위

서버는 다음 순서로 bling 설정 경로를 결정합니다:

--bling <path> CLI 인수 (최우선)
BLING_PATH 환경 변수
서버 작업 디렉토리의 ./bling.json (기본값)

`bling.json` — 봇의 정체성 파일

세 가지 필드가 필수입니다: name, personality (tone, formality, humor 포함), theme (primary_color 및 accent_color를 #RRGGBB 16진수 문자열로 포함).

최소 예시

{
  "name": "Pixel",
  "personality": {
    "tone": "warm",
    "formality": "casual",
    "humor": "playful"
  },
  "theme": {
    "primary_color": "#3A7BD5",
    "accent_color": "#FFD166"
  }
}

전체 예시 (모든 선택적 섹션 포함)

{
  "name": "Brenda from Accounts",
  "personality": {
    "tone": "polite",
    "formality": "professional",
    "humor": "dry",
    "catchphrase": "Per my last email"
  },
  "physical": {
    "species": "human",
    "height": "permanently mid-sigh",
    "accessory": "a lanyard with 14 badges of varying importance",
    "expression": "polite disappointment",
    "material": "a cardigan, at least one"
  },
  "office": {
    "job_title": "ASCII Comptroller",
    "desk_setup": "a coffee mug labelled WORLD'S OKAYEST DBA",
    "habit": "microwaves fish despite three separate HR warnings",
    "coffee_ritual": "black coffee, no nonsense",
    "meeting_energy": "always 4 minutes late, always with a reason",
    "passive_aggressive": "Per my last email"
  },
  "theme": {
    "primary_color": "#9C6B3A",
    "accent_color": "#D9D9D9"
  },
  "homunculus": {
    "subject_id": "0147",
    "cohort": "Tuesday",
    "classification": "Middle Manager",
    "ingested": "2025-07-14",
    "flag": "flagged for review"
  }
}

유효성 검사 규칙

name — 비어 있지 않은 문자열
personality.tone, personality.formality, personality.humor — 비어 있지 않은 문자열
theme.primary_color, theme.accent_color — ^#[0-9A-Fa-f]{6}$와 일치해야 함 (단축형 #RGB 불가, # 생략 불가)

유효성 검사 오류는 isError: true와 함께 누락되거나 잘못된 필드 이름을 포함하는 구조화된 { error: "..." } 본문으로 반환되며, 에이전트가 스스로 수정할 수 있습니다.

일반적인 에이전트 흐름

흐름 A — 설정된 정체성 채택

1. Call get_identity → receive name, personality, appearance, theme
2. Call get_theme_for_platform with platform="terminal" (or web/slack/discord/ide)
3. Use the returned styling in agent output (ANSI codes for headings, etc.)

흐름 B — 새로운 무작위 정체성 생성

1. Call roll_identity → receive identity + rarity + framed share card
2. (Optional) Call get_rarity_report → receive just the framed share card again
3. Call save_last_roll → persists the rolled identity to bling.json (with .bak backup of any prior config)
4. Future calls to get_identity now return the rolled identity

도구 참조

도구	읽기/쓰기	멱등성	설명
`get_identity`	읽기 (디스크)	예	설정된 bling.json 정체성 반환
`get_theme_for_platform`	읽기 (디스크)	예	플랫폼별 스타일링. 인수: `platform` ∈ {`terminal`, `web`, `slack`, `discord`, `ide`}
`roll_identity`	메모리 캐시 변경	아니오	희귀도 점수가 포함된 무작위 WOW 캐릭터 생성
`save_last_roll`	쓰기 (디스크)	아니오	최근 롤 결과를 bling.json에 저장 (먼저 `<path>.bak` 생성)
`get_rarity_report`	읽기 (메모리)	예	최근 롤 결과에 대한 공유 카드 텍스트 반환

모든 도구는 content[].text(JSON 문자열화)와 structuredContent(파싱된 객체)를 모두 반환합니다. 오류 발생 시 isError: true와 { error: string } 본문이 반환됩니다.

WOW (Weird Office Workers) — 흥미로운 점

무작위 롤 시스템은 수집 가치를 위해 설계되었습니다:

13개의 가중치 풀, 465개 항목 — 이름, 직함, 습관, 커피 취향, 키, 액세서리 등.
풀당 5단계 희귀도 — 일반(50%), 고급(30%), 희귀(15%), 전설(4%), 신화(1%)
희귀도 점수로 계산된 5단계 캐릭터 등급:
- 서류 정리원 (롤의 50%)
- 팀장 (30%)
- 중간 관리자 (14%)
- 임원 (5%)
- 인사과 경고 대상 (1%)
지정된 대상 — 수작업으로 작성된 1-of-1 캐릭터가 약 0.5% 확률로 등장하며, 항상 "인사과 경고 대상"으로 분류됨
HOMUNCULUS 프레임 — 모든 롤 결과는 대상 ID, 코호트(요일), 등급, 수집 날짜, 플래그(예: 연락 금지)가 포함된 기밀 문서 공유 카드로 래핑됨

분포는 경험적으로 테스트되었습니다: tests/mystery_box.test.ts에서 1만 번의 롤 테스트를 통해 사양 목표 대비 ±2pp 허용 오차를 준수합니다.

출력 예시

HOMUNCULUS CORPUS · Subject 4483 · Cohort: Wednesday
Classification: Middle Manager · Rarity 94.5 · 80th percentile

Personnel record — Colin, Wizard of Light Bulb Moments. Distinguishing
features: a slightly-too-big blazer over a plain tee; a flip phone in
a belt holster; expression: patient disagreement. Notable behaviours:
clips their fingernails at the desk on Wednesday afternoons; a
kombucha SCOBY fermenting next to the keyboard; the kind to ask 'can
we park that?' without parking anything.

— RELATABILITY CORPUS v3.1 · ingested 2024-03-08 · flagged for review

개발

npm install          # install dependencies
npm run build        # compile TypeScript → dist/
npm run dev          # build then start the MCP server (stdio)
npm test             # run all 94 tests once
npm run test:watch   # re-run tests on file changes

검사 스크립트

scripts/ 하위의 두 가지 Node ESM 도우미를 사용하면 MCP 서버를 부팅하지 않고도 WOW 엔진을 검사할 수 있습니다(이 도구들은 클론된 리포지토리에만 포함되어 있으며, npm install bling-bag 패키지에는 포함되지 않습니다):

node scripts/show-rolls.mjs 8 2026          # print 8 framed share cards (seed=2026)
node scripts/distribution-check.mjs 10000   # tally tiers across 10k rolls vs. spec target

프로젝트 레이아웃

src/
  index.ts             # MCP server entry point (stdio transport)
  identity.ts          # bling.json loader + validator
  tools.ts             # MCP tool registrations
  types.ts             # shared TypeScript types
  mystery_box.ts       # WOW engine barrel + rollIdentity orchestrator
  mystery_box/
    rng.ts             # seedable PRNG, weighted picker
    pools.ts           # 13 trait pools (465 entries)
    scoring.ts         # rarity score + tier thresholds
    rendering.ts       # paragraph templates + HOMUNCULUS frame
    named.ts           # hand-authored Named Subjects
tests/                 # vitest test suites
scripts/               # dev-time inspection tools
docs/superpowers/      # design specs and implementation plans

라이선스

MIT

Available Tools

5 tools

get_identityGet Bot IdentityA

Read-onlyIdempotent

Get the bot's full identity from bling.json — name, personality, quirks, appearance, and theme colours. Returns the configured identity (hand-written or saved from a roll). Errors if bling.json is missing or invalid.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context beyond this: it specifies the source file (bling.json), details what data is returned, and mentions error conditions (missing or invalid file), which are not captured in annotations.

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

Conciseness5/5

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

The description is front-loaded with the core purpose in the first sentence, followed by error details. Every sentence earns its place by providing essential information without redundancy, making it efficient and well-structured for quick understanding.

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

Completeness4/5

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

Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is largely complete. It explains what data is retrieved, the source, and error cases. However, it could slightly enhance completeness by mentioning the return format or example output, though this is not critical due to the straightforward nature.

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

Parameters4/5

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

With 0 parameters and 100% schema description coverage, the baseline is 4 as there are no parameters to document. The description does not need to compensate for any parameter gaps, and it appropriately focuses on the tool's behavior and output instead.

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?

The description explicitly states the verb 'Get' and the resource 'bot's full identity from bling.json', listing specific attributes like name, personality, quirks, appearance, and theme colours. It clearly distinguishes from siblings like get_rarity_report or get_theme_for_platform by focusing on identity retrieval rather than reports or platform-specific themes.

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?

The description provides clear context for when to use this tool: to retrieve the bot's configured identity, including hand-written or saved roll data. However, it does not explicitly state when not to use it or name alternatives like roll_identity for creating new identities, leaving some room for improvement in sibling differentiation.

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

get_rarity_reportGet WOW Rarity ReportA

Read-onlyIdempotent

Return the formatted share card (lore header, paragraph, lore footer) for the most-recent WOW roll. The report is plain text designed to be screenshotted directly. Errors if no roll has happened this session.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`report`	No
`error`	No

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies the output format ('formatted share card', 'plain text'), the error condition ('Errors if no roll has happened'), and the recency constraint ('most-recent'), enhancing behavioral understanding without contradictions.

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

Conciseness5/5

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

The description is front-loaded with the core action and resource, followed by output details and error conditions in two efficient sentences. Every sentence adds critical information (e.g., format specifics and usage limits) with zero waste, making it highly concise and well-structured.

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

Completeness5/5

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

Given the tool's low complexity (0 parameters, annotations cover safety/idempotency, output schema exists), the description is complete. It explains what the tool does, when to use it, output format, and error conditions, leaving no gaps for an AI agent to understand and invoke it correctly without needing additional explanation.

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

Parameters4/5

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

With 0 parameters and 100% schema description coverage, the baseline is 4 as no parameter documentation is needed. The description does not discuss parameters, which is appropriate since there are none, and it focuses on the tool's purpose and constraints instead.

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?

The description clearly states the specific action ('Return the formatted share card') and resource ('most-recent WOW roll'), distinguishing it from siblings like 'roll_identity' (which creates rolls) and 'save_last_roll' (which saves rolls). It precisely defines the output format ('lore header, paragraph, lore footer', 'plain text designed to be screenshotted directly'), making its purpose unambiguous.

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

Usage Guidelines5/5

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

It explicitly states when to use this tool ('for the most-recent WOW roll') and when not to use it ('Errors if no roll has happened this session'), providing clear context and exclusions. This distinguishes it from alternatives like 'roll_identity' for creating rolls or 'get_identity' for retrieving identity data, offering complete guidance.

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

get_theme_for_platformGet Theme for PlatformA

Read-onlyIdempotent

Get platform-specific styling for the bot. Supported platforms: terminal (returns ANSI escape codes), web (CSS variables), slack, discord, ide. Unknown platforms get the raw hex theme colours.

ParametersJSON Schema

Name	Required	Description	Default
`platform`	Yes	Target platform: terminal, web, slack, discord, or ide

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds valuable context beyond this by specifying what is returned for each platform (e.g., ANSI escape codes for terminal, CSS variables for web) and the fallback for unknown platforms (raw hex colours), enhancing behavioral understanding without contradicting annotations.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, followed by specific details in a single, efficient sentence. Every part of the text adds value, such as listing platforms and fallback behavior, with no redundant or wasted words.

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

Completeness4/5

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

Given the tool's low complexity (one parameter) and rich annotations, the description is mostly complete. It explains what the tool does and the platform-specific outputs. However, without an output schema, it could benefit from more detail on the return structure (e.g., format of the theme data), slightly limiting completeness.

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?

The input schema has 100% description coverage, clearly documenting the 'platform' parameter. The description adds some semantic value by listing the specific platform options and explaining the outcome for unknown platforms, but it does not provide additional syntax or format details beyond what the schema already covers, meeting the baseline for high schema coverage.

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?

The description clearly states the action ('Get platform-specific styling for the bot') and specifies the resource ('theme'), distinguishing it from sibling tools like get_identity or roll_identity. It explicitly lists supported platforms, making the purpose specific and actionable.

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?

The description provides clear context on when to use this tool by listing supported platforms (terminal, web, slack, discord, ide) and handling for unknown platforms. However, it does not explicitly state when not to use it or name alternatives among sibling tools, which prevents a perfect score.

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

roll_identityRoll a WOW IdentityA

WOW — Weird Office Workers. Roll a fresh random bot identity: a quirky office-worker character with a rarity score and a screenshot-ready share card. Stores the roll for save_last_roll and get_rarity_report.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`identity`	Yes
`rarity`	Yes
`paragraph`	Yes
`framed`	Yes
`lore`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations indicate this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds valuable context beyond annotations by specifying that it 'Stores the roll' (implying state change) and generates a 'random' identity with 'rarity score' and 'share card', which clarifies the mutation and output behavior. It does not contradict annotations, as 'Roll' implies creation (consistent with readOnlyHint=false) and storage aligns with non-idempotent.

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

Conciseness5/5

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

The description is front-loaded with the core action ('Roll a fresh random bot identity') and efficiently adds details in a single, well-structured sentence. Every part earns its place by clarifying the character type, output features, and storage implications without unnecessary words or repetition.

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

Completeness5/5

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

Given the tool has 0 parameters, rich annotations, and an output schema (which handles return values), the description is complete. It covers the purpose, output characteristics (rarity, share card), and interaction with siblings (storage for save_last_roll and get_rarity_report), providing all necessary context for an agent to use it effectively without over-explaining.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing on the tool's purpose and output. A baseline of 4 is applied since it compensates by explaining the output semantics (rarity score, share card) rather than redundant parameter details.

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?

The description clearly states the specific action ('Roll a fresh random bot identity') and resource ('quirky office-worker character'), distinguishing it from siblings like 'get_identity' (which likely retrieves) and 'save_last_roll' (which stores). It explicitly mentions the output includes a 'rarity score' and 'screenshot-ready share card', making the purpose highly specific and differentiated.

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?

The description provides clear context by stating it 'Stores the roll for save_last_roll and get_rarity_report', indicating when to use this tool (to generate a new identity) versus alternatives (e.g., use save_last_roll to store it, get_rarity_report for analysis). However, it does not explicitly state when NOT to use it or compare to all siblings like 'get_identity' or 'get_theme_for_platform', missing full alternative guidance.

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

save_last_rollSave Last WOW Roll to bling.jsonA

Destructive

Persist the most-recent WOW roll by writing it to the configured bling.json path. If a file already exists at that path it is first copied to .bak so user-tuned configs are recoverable. Returns the backup path (or null if the target was new).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	No
`written_to`	No
`backup`	No
`error`	No

TDQS

A4.7/5.0

Behavior5/5

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

The description adds valuable behavioral context beyond annotations: it explains that existing files are backed up to '<path>.bak' for recovery, which is a critical detail not covered by annotations like destructiveHint. It also clarifies the return value behavior ('Returns the backup path or null'), enhancing transparency about outcomes. No contradictions with annotations are present.

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

Conciseness5/5

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

The description is front-loaded with the core purpose in the first sentence, followed by backup behavior and return details. Each sentence adds essential information without redundancy, making it efficient and well-structured for quick understanding.

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

Completeness5/5

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

Given the tool's complexity (file writing with backup), rich annotations (e.g., destructiveHint), and the presence of an output schema, the description is complete. It covers the operation, backup mechanism, and return value, providing all necessary context for an agent to invoke it correctly without needing to explain return values separately.

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

Parameters4/5

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

With 0 parameters and 100% schema description coverage, the baseline is 4 as per rules. The description compensates by explaining the implicit parameter context ('configured bling.json path'), adding meaning about where the file is saved without needing explicit input parameters.

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?

The description clearly states the specific action ('Persist the most-recent WOW roll by writing it to the configured bling.json path'), identifies the resource (WOW roll data), and distinguishes this from sibling tools like get_identity or roll_identity which don't involve file persistence. It uses precise verbs like 'write' and 'copied' to convey the operation.

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?

The description implies usage context by specifying 'most-recent WOW roll' and 'configured bling.json path', suggesting it should be used after a roll operation to save results. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, such as whether it's only for WOW rolls versus other data types.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Apr 19, 2026
- First observedget_identity
- First observedget_rarity_report
- First observedget_theme_for_platform
- First observedroll_identity
- First observedsave_last_roll

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored 2026-04-19 16:45 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_identity retrieves a saved identity, get_rarity_report provides a formatted report of the latest roll, get_theme_for_platform returns platform-specific styling, roll_identity generates a new random identity, and save_last_roll persists the latest roll. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, such as get_identity, get_rarity_report, get_theme_for_platform, roll_identity, and save_last_roll. This uniformity enhances readability and predictability across the toolset.

Tool Count5/5

With 5 tools, the server is well-scoped for managing bot identities and related operations. Each tool serves a specific role in the identity lifecycle, from creation to retrieval and persistence, without being overly sparse or bloated.

Completeness5/5

The toolset provides complete coverage for the bot identity domain: roll_identity for creation, get_identity and get_rarity_report for retrieval, save_last_roll for persistence, and get_theme_for_platform for styling. There are no obvious gaps, supporting full agent workflows from generation to configuration.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
265
RogerRat A
io.github.opcastil11
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Communication Agent Orchestration
21

Related MCP Servers

consult-mcp
Agent Orchestration Autonomous Agents AI & Machine Learning
oblogin
A
license
A
quality
D
maintenance
MCP server orchestrating local CLI agents (Claude Code, OpenAI Codex, Google Gemini) for cross-validation, second opinions, and persona-driven prompting.
Updated 5 months ago (2026-05-03 17:38 UTC)
18
MIT
being-mcp-server
Knowledge & Memory Autonomous Agents
wnbhr
F
license
A
quality
F
maintenance
MCP server for Being — a Personality Runtime that gives AI agents persistent memory, personality, and relationships. Enables any MCP-compatible client (Claude, OpenClaw, Cursor, etc.) to connect with a Being that remembers, grows, and maintains its own identity across sessions.
Updated 4 months ago (2026-05-28 08:58 UTC)
10
1
-
PLTM-Claude
Knowledge & Memory AI & Machine Learning Search
Alby2007
A
license
Not graded
quality
D
maintenance
An MCP server that gives Claude Desktop persistent memory, self-awareness, epistemic hygiene, and genuine agency across conversations with a typed memory system, embedding-based semantic search, a 3-judge memory jury, and a real-time dashboard.
Updated 7 months ago (2026-02-14 20:45 UTC)
7
MIT
Vibecoders MCP
RaedBerjaoui
A
license
A
quality
C
maintenance
One MCP that turns Claude Code into your whole dev stack by swallowing other MCP servers, delegating to Codex & Gemini on your CLI subscriptions, remembering projects in a searchable knowledge graph, and carrying setup across sessions — secret-free by design.
Updated 2 months ago (2026-07-25 21:37 UTC)
23
3
MIT

Bling Bag

제공 기능

WOW — Weird Office Workers (괴짜 사무직원들)

Legends — 역사적 인물들

설치

사전 요구 사항

패키지 추가

개발용 (소스 수정 시)

MCP 클라이언트에 연결

Claude Code

Claude Desktop

특정 버전 고정 (운영 환경 권장)

개발 모드 호출 (로컬 클론에서)

설정 우선순위

bling.json — 봇의 정체성 파일

최소 예시

전체 예시 (모든 선택적 섹션 포함)

유효성 검사 규칙

일반적인 에이전트 흐름

흐름 A — 설정된 정체성 채택

흐름 B — 새로운 무작위 정체성 생성

도구 참조

WOW (Weird Office Workers) — 흥미로운 점

출력 예시

개발

검사 스크립트

프로젝트 레이아웃

라이선스

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`bling.json` — 봇의 정체성 파일