Crescender의 공개 읽기 전용 API를 위한 Model Context Protocol 서버입니다. AI 클라이언트(Claude Desktop, Cursor, 커스텀 에이전트)를 학교의 자산, 대출, 구성원 및 자산 통신 스레드에 연결합니다. 모든 기능은 읽기 전용이며, 스코프 토큰 인증을 사용하고 토큰당 하나의 학교에 바인딩됩니다.
상태: 0.0.x — 게시 전. 이 패키지는 아직 npm에 게시되거나 GHCR에 푸시되지 않았습니다. 게시 파이프라인은 존재하지만 수동 트리거로 제한되어 있습니다. 첫 번째 릴리스는 소스가 로컬에서 충분히 테스트된 후 배포될 예정입니다. 현재는 클론을 실행하거나
pnpm link를 사용하십시오(로컬 개발 참조).
각각 /api/v1/* 엔드포인트를 지원하는 6개의 읽기 전용 도구:
MCP 도구 | 반환 값 |
| 토큰이 바인딩된 단일 학교(단일 항목 배열) |
| ID별 전체 자산 세부 정보 — 모델, 일련번호, 위치, 역할, 현재 대출 상태 |
|
|
| 단일 자산에 대한 대출 기록(현재 + 과거) |
| 구성원 디렉토리 — ID, 역할, 상태, external_id (개인정보 제외) |
| 상태 필터가 적용된 자산 통신 스레드 (읽기 전용 — 공급업체 토큰 발급은 MCP를 통해 노출되지 않음) |
읽기 전용입니다. v1에는 update_* / create_* 도구가 없습니다.
Related MCP server: OfficeRnD MCP Server
두 개의 환경 변수가 필요하며, 그중 하나는 필수입니다:
변수 | 기본값 | 참고 |
| — | 필수. |
|
| 프로덕션이 아닌 배포 환경을 가리키는 경우에만 재정의하세요. |
|
|
|
|
| 컨테이너 배포 시 |
|
| 요청당 업스트림 타임아웃 시간. |
첫 번째 버전이 npm에 게시되면:
// ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
// %APPDATA%\Claude\claude_desktop_config.json (Windows)
{
"mcpServers": {
"crescender": {
"command": "npx",
"args": ["-y", "@crescender/mcp-server"],
"env": {
"CRESCENDER_API_TOKEN": "crsc_..."
}
}
}
}그런 다음 Claude Desktop을 다시 시작하십시오. 6개의 도구가 MCP 선택기에 나타나야 합니다.
Cursor는 작업 공간의 .cursor/mcp.json 또는 설정에서 전역적으로 MCP 구성을 읽습니다. 구조는 Claude Desktop의 mcpServers 블록과 동일합니다.
# Install
git clone https://github.com/lincalinca/crescender-mcp-server.git
cd crescender-mcp-server
pnpm install
# Build
pnpm build
# Smoke test (talks to stdin/stdout — Claude Desktop / Cursor will spawn it
# the same way)
CRESCENDER_API_TOKEN=crsc_... node dist/index.js게시하지 않고 로컬 클론을 Claude Desktop에 연결하려면:
{
"mcpServers": {
"crescender-local": {
"command": "node",
"args": ["/absolute/path/to/crescender-mcp-server/dist/index.js"],
"env": {
"CRESCENDER_API_TOKEN": "crsc_..."
}
}
}
}# Build (the published image is built by .github/workflows/publish-image.yml)
docker build -t crescender-mcp-server:dev .
# Run with the in-container /health endpoint enabled
docker run --rm -i \
-e CRESCENDER_API_TOKEN=crsc_... \
-e CRESCENDER_MCP_HEALTH=1 \
-p 3030:3030 \
crescender-mcp-server:dev게시되면 이미지는 ghcr.io/lincalinca/crescender-mcp-server에서 사용할 수 있습니다.
메모리 내 토큰 캐시 없음: 모든 호출 시 업스트림 API를 검증합니다(즉시 취소 가능).
파일 시스템 상태 없음: stdout/stderr만 사용.
구성은 환경 변수 기반이며, 부팅 시 한 번 파싱되고 고정됩니다.
/health(활성화 시)는 { ok, api_reachable, version }을 반환하며, 단순히 "프로세스가 살아있는지" 확인하는 것이 아니라 업스트림 /api/v1/health를 프로빙하여 도달 가능성을 확인합니다.
정상 종료: SIGTERM / SIGINT는 30초간의 드레인(drain)을 트리거한 후 강제 종료합니다.
이것이 컨테이너를 k8s 전용 코드 없이 k8s 준비 상태로 만드는 이유입니다. 오케스트레이션 결정(ASK / AKS / GKE / Fly / Railway 등)이 나중에 내려지더라도 여기서는 아무것도 변경되지 않습니다.
MIT — LICENSE를 참조하십시오.
@crescender/crescender-core — 이 MCP가 래핑하는 /api/v1 엔드포인트를 제공하는 플랫폼 자체입니다.
OpenAPI 사양: https://app.crescender.com.au/api/v1/openapi.json
Get full detail for a single asset (instrument, equipment, sub-item) by id. Includes model, serial, location, role, and the current loan if any.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | Asset uuid (the gear's id field). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It implies read-only but does not explicitly state non-destructive behavior, required permissions, or error cases. It adds value by mentioning the return of 'current loan'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It effectively conveys the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description lists key fields returned, covering the main use case. Could mention behavior when asset not found, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description adds context about what is returned but does not add parameter-level details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get full detail') and resource ('single asset'), and lists included fields. It distinguishes from siblings like 'search_assets' by focusing on retrieval by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for single asset detail but lacks explicit guidance on when to use alternatives (e.g., search_assets for filtering). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the loan history for a single asset. Currently returns whatever loans field is embedded on the asset detail; in a future version may paginate independently.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | Asset uuid. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses current behavior (returns embedded loans field) and a future change (independent pagination), adding valuable context beyond the schema. However, it omits details like whether the operation is read-only or any authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: the first states the core purpose, the second adds behavioral nuance. Every sentence is purposeful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the function and current behavior. It could be slightly more complete by hinting at the format of the loan history, but the note about the embedded field provides reasonable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'asset_id' as 'Asset uuid.' The description adds no further parameter semantics, so it meets the baseline of 3 given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the loan history for a single asset,' specifying the action (get) and resource (loan history for asset). This distinguishes it from siblings like get_asset (general details) and list_asset_threads (threads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when loan history for a single asset is needed, but offers no explicit when-to or when-not-to use compared to alternatives. No sibling tools serve the same purpose, so context is clear but guidelines are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List asset-comms threads (vendor / repair / service conversations attached to assets). Read-only — vendor-token issuance is NOT exposed via this MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status: 'open', 'scheduled', 'closed', etc. | |
| cursor | No | Opaque pagination cursor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the read-only nature but does not cover pagination behavior, error conditions, or what happens when no threads exist. The mention of vendor-token issuance being excluded is a limitation but not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the purpose, followed by a key behavioral note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 optional parameters and no output schema, the description adequately explains what the tool does and its read-only nature. It could benefit from mentioning pagination details or return format, but for a simple list tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (status, cursor). The description adds context about the resource (vendor/repair/service conversations) but does not enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'asset-comms threads', specifying that these are vendor/repair/service conversations attached to assets. This distinguishes it from sibling tools like get_asset or search_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Read-only' and clarifies that vendor-token issuance is NOT exposed, indicating when to use this tool (for reading threads) and what not to expect. However, it does not contrast with sibling tools like search_assets for broader asset searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the school's members. Returns id, role, status, external_id only — no PII (email/phone are intentionally excluded from the public API).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Filter by role: 'student', 'teacher', 'staff', etc. | |
| status | No | Lifecycle: 'active', 'inactive'. | |
| cursor | No | Opaque pagination cursor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the important exclusion of PII, but does not mention pagination behavior (cursor usage, limits), performance implications, or whether the list is ordered. This is a moderate gap for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first defines purpose, second adds critical behavioral caveat. No redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three optional parameters and no output schema, the description covers the basic purpose and a key constraint (no PII). However, it lacks details on pagination, ordering, and expected response format, which would be helpful without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions. The tool description does not add any parameter-specific semantics beyond the schema. The only added value is about the output (returned fields), not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists school members and specifies the exact fields returned (id, role, status, external_id). It also explicitly excludes PII, setting clear expectations. This distinguishes it from sibling tools which focus on assets and loans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: the tool is for listing members. Sibling tools are about assets and schools, so the usage context is implied. However, there is no explicit guidance on when to use this tool versus alternatives, nor any caveats about filtering or pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List schools accessible to the calling token. Each token is bound to exactly one school, so this returns a single-item array. Useful for the AI to confirm which school it's looking at before making other calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It correctly discloses that the tool returns a single-item array due to token binding and implies it is a read-only operation, which is sufficient for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and provide essential behavior details without any wasted words. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description adequately explains that the result is a single-item array. For a simple, parameterless list tool, this provides sufficient context for an AI to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% trivially. The description adds value by explaining the return behavior, which goes beyond the schema. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists schools accessible to the token, and explains the unique behavior that each token is bound to one school, returning a single-item array. This distinguishes it from sibling tools like get_asset or list_members, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly suggests using this tool 'to confirm which school it's looking at before making other calls,' providing clear context for when to invoke it. However, it does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the school's assets by free-text query and/or filters. Returns up to 50 matches per page. Use the cursor field from the response to fetch the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text query (matches name, model, serial). | |
| item_class | No | Filter by class: 'instrument', 'equipment', 'consumable', etc. | |
| category | No | Domain category (e.g. 'brass', 'percussion', 'av'). | |
| status | No | Lifecycle: 'active', 'retired', 'in_repair', etc. | |
| cursor | No | Opaque pagination cursor from a prior response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It discloses pagination (50 per page, cursor) but omits auth requirements, response structure, and whether operations are read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines purpose, second covers pagination. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fails to hint at the response shape (e.g., list of asset objects). Pagination is covered, but the overall completeness is lacking for a search tool with 5 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions; description adds no new semantic info beyond confirming free-text and filter usage, meeting the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches school assets by free-text query and filters, using a specific verb and resource, and distinguishes from siblings like get_asset (single asset) and list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Pagination guidance is provided, but no explicit advice on when to use this tool versus alternatives like get_asset for a specific asset or list_members for members.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.1get_assetget_loans_for_assetlist_asset_threadslist_memberslist_schoolssearch_assetsScored across 6 tools
Each tool targets a distinct resource or action: get_asset and search_assets are clearly different (detail vs. search), and loan history, threads, members, and schools are all separate concerns. No overlapping purposes.
All tools consistently follow the 'verb_noun' pattern in lowercase snake_case (e.g., get_asset, list_asset_threads, search_assets). The naming is uniform and predictable.
6 tools is well-scoped for an asset management server. Each tool covers a core area without being overwhelming or insufficient.
The tool surface is heavily read-only: assets have get and search but no create/update/delete; loans only show history; threads only list; members and schools only list. Missing basic write operations for the domain.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Read-only MCP server exposing a user ORANO library to their own AI agent.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Read-only MCP server for the OPERANT AI operating-agent calibration benchmark.
