Crescender の公開読み取り API 用の Model Context Protocol サーバーです。AI クライアント（Claude Desktop、Cursor、カスタムエージェント）を、学校の資産、貸出、メンバー、および資産通信スレッドに接続します。すべて読み取り専用で、スコープトークン認証が行われ、トークンごとに 1 つの学校に紐付けられます。
ステータス: 0.0.x — 公開前。 このパッケージはまだ npm に公開されておらず、GHCR にもプッシュされていません。公開パイプラインは存在しますが、手動トリガーに制限されています。最初のリリースは、ソースがローカルで十分にテストされた後に行われます。現時点では、クローンから実行するか、
pnpm linkを使用してください（以下の ローカル開発 を参照）。
6 つの読み取り専用ツール。それぞれが /api/v1/* エンドポイントによってサポートされています。
MCP ツール | 戻り値 |
| トークンが紐付けられている単一の学校（単一要素の配列） |
| ID による資産の詳細（モデル、シリアル番号、場所、役割、現在の貸出状況） |
|
|
| 1 つの資産の貸出履歴（現在および過去） |
| メンバーディレクトリ（ID、役割、ステータス、external_id。個人情報は含まれません） |
| ステータスフィルター付きの資産通信スレッド（読み取り専用。ベンダートークンの発行は MCP を介して公開されません） |
読み取り専用です。v1 には update_* / create_* ツールはありません。
Related MCP server: OfficeRnD MCP Server
2 つの環境変数（うち 1 つは必須）:
変数 | デフォルト | 備考 |
| — | 必須。 |
|
| 本番環境以外のデプロイメントを指す場合にのみ上書きしてください。 |
|
|
|
|
| コンテナデプロイメントで |
|
| リクエストごとのアップストリームタイムアウト。 |
最初のバージョンが 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 を再起動してください。MCP ピッカーに 6 つのツールが表示されるはずです。
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 秒間のドレインをトリガーし、その後強制終了します。
これにより、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.
