Сервер Model Context Protocol для публичного API Crescender только для чтения. Подключает ИИ-клиентов (Claude Desktop, Cursor, пользовательских агентов) к активам школы, займам, участникам и веткам коммуникаций по активам — всё это доступно только для чтения, аутентифицируется через scope-токен и привязано к одной школе на токен.
Статус: 0.0.x — до публикации. Этот пакет еще не был опубликован в npm или отправлен в GHCR. Пайплайны публикации существуют, но требуют ручного запуска; первый релиз будет выпущен после того, как исходный код пройдет проверку в локальной среде. На данный момент запускайте из клона или используйте
pnpm link(см. Локальная разработка ниже).
Шесть инструментов только для чтения, каждый из которых работает через эндпоинт /api/v1/*:
MCP-инструмент | Возвращает |
| Единственную школу, к которой привязан токен (массив из одного элемента) |
| Полные данные об активе по id — модель, серийный номер, местоположение, роль, текущий заем |
| До 50 активов, соответствующих |
| Историю займов для одного актива (текущие + прошлые) |
| Справочник участников — id, роль, статус, external_id (без PII) |
| Ветки коммуникаций по активам с фильтром по статусу (только чтение — выдача токенов поставщика НЕ предоставляется через 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. Шесть инструментов должны появиться в меню выбора MCP.
Cursor считывает конфигурацию MCP из файла .cursor/mcp.json в вашем рабочем пространстве или глобально из настроек. Структура такая же, как у блока mcpServers в 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.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 — сама платформа, которая обслуживает эндпоинты /api/v1, обернутые этим MCP.
Спецификация 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.
