Model Context Protocol-Server für die öffentliche Lese-API von Crescender. Verbindet KI-Clients (Claude Desktop, Cursor, benutzerdefinierte Agenten) mit den Ressourcen, Ausleihen, Mitgliedern und Asset-Kommunikations-Threads einer Schule – alles schreibgeschützt, per Scope-Token authentifiziert und pro Token an eine einzige Schule gebunden.
Status: 0.0.x — vor der Veröffentlichung. Dieses Paket wurde noch nicht auf npm veröffentlicht oder in die GHCR gepusht. Die Veröffentlichungs-Pipelines existieren, sind aber auf manuelle Auslösung beschränkt; die erste Version erscheint, sobald der Quellcode lokal auf Herz und Nieren geprüft wurde. Führen Sie das Programm vorerst über einen Klon oder
pnpm linkaus (siehe Lokale Entwicklung unten).
Sechs schreibgeschützte Tools, die jeweils durch einen /api/v1/*-Endpunkt unterstützt werden:
MCP-Tool | Rückgabe |
| Die einzelne Schule, an die das Token gebunden ist (Array mit einem Element) |
| Vollständige Asset-Details nach ID – Modell, Seriennummer, Standort, Rolle, aktuelle Ausleihe |
| Bis zu 50 Assets, die mit |
| Ausleihhistorie für ein Asset (aktuell + vergangen) |
| Mitgliederverzeichnis – ID, Rolle, Status, external_id (keine PII) |
| Asset-Kommunikations-Threads mit Statusfilter (schreibgeschützt – die Ausgabe von Vendor-Tokens wird NICHT über MCP bereitgestellt) |
Nur Lesezugriff. Keine update_* / create_*-Tools in v1.
Related MCP server: OfficeRnD MCP Server
Zwei Umgebungsvariablen, eine davon erforderlich:
Var | Standard | Hinweise |
| — | Erforderlich. Zu beziehen über |
|
| Nur überschreiben, wenn Sie auf eine Nicht-Produktionsumgebung verweisen. |
|
| Einer der Werte |
|
| In Container-Deployments auf |
|
| Upstream-Timeout pro Anfrage. |
Sobald die erste Version auf npm verfügbar ist:
// ~/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_..."
}
}
}
}Starten Sie anschließend Claude Desktop neu. Die sechs Tools sollten in der MCP-Auswahl erscheinen.
Cursor liest die MCP-Konfiguration aus .cursor/mcp.json in Ihrem Arbeitsbereich oder global aus den Einstellungen. Die Struktur entspricht dem mcpServers-Block von Claude Desktop.
# 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.jsUm Ihren lokalen Klon ohne Veröffentlichung in Claude Desktop einzubinden:
{
"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:devNach der Veröffentlichung wird das Image unter ghcr.io/lincalinca/crescender-mcp-server verfügbar sein.
Kein In-Memory-Token-Cache: Die Validierung erfolgt bei jedem Aufruf über die Upstream-API (Widerruf erfolgt sofort).
Kein Dateisystem-Status: Nur stdout/stderr.
Die Konfiguration ist umgebungsgesteuert, wird beim Booten einmal geparst und dann eingefroren.
/health (sofern aktiviert) gibt { ok, api_reachable, version } zurück und prüft den Upstream /api/v1/health, um die Erreichbarkeit zu verifizieren – nicht nur "dieser Prozess lebt".
Graceful Shutdown: SIGTERM / SIGINT lösen ein 30-sekündiges "Drain" aus und erzwingen dann das Beenden.
Dies macht den Container k8s-bereit, ohne dass k8s-spezifischer Code erforderlich ist. Wenn die Orchestrierungsentscheidung schließlich getroffen wird (ASK / AKS / GKE / Fly / Railway / etc.), ändert sich hier nichts.
MIT – siehe LICENSE.
@crescender/crescender-core – die Plattform selbst, die die /api/v1-Endpunkte bereitstellt, die dieses MCP umschließt.
OpenAPI-Spezifikation: 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.
