Servidor del Protocolo de Contexto de Modelo (MCP) para la API pública de solo lectura de Crescender. Conecta clientes de IA (Claude Desktop, Cursor, agentes personalizados) con los activos, préstamos, miembros e hilos de comunicaciones de activos de una escuela; todo en modo de solo lectura, autenticado mediante token de alcance y vinculado a una única escuela por token.
Estado: 0.0.x — pre-publicación. Este paquete aún no se ha publicado en npm ni se ha enviado a GHCR. Las canalizaciones de publicación existen pero están restringidas a activadores manuales; la primera versión se lanzará cuando el código fuente haya sido probado bajo presión localmente. Por ahora, ejecútelo desde un clon o un
pnpm link(consulte Desarrollo local a continuación).
Seis herramientas de solo lectura, cada una respaldada por un endpoint /api/v1/*:
Herramienta MCP | Devuelve |
| La única escuela a la que está vinculado el token (matriz de un solo elemento) |
| Detalle completo del activo por id: modelo, serie, ubicación, rol, préstamo actual |
| Hasta 50 activos que coincidan con |
| Historial de préstamos de un activo (actual + pasado) |
| Directorio de miembros: id, rol, estado, external_id (sin PII) |
| Hilos de comunicaciones de activos con filtro de estado (solo lectura: la emisión de tokens de proveedor NO se expone a través de MCP) |
Solo lectura. No hay herramientas update_* / create_* en la v1.
Related MCP server: OfficeRnD MCP Server
Dos variables de entorno, una de ellas obligatoria:
Var | Predeterminado | Notas |
| — | Obligatorio. Emítalo desde |
|
| Solo sobrescriba si apunta a una implementación que no sea de producción. |
|
| Uno de |
|
| Establézcalo en |
|
| Tiempo de espera ascendente por solicitud. |
Una vez que la primera versión esté en 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_..."
}
}
}
}Luego reinicie Claude Desktop. Las seis herramientas deberían aparecer en el selector de MCP.
Cursor lee la configuración de MCP desde .cursor/mcp.json en su espacio de trabajo, o globalmente desde la configuración. La forma es la misma que el bloque mcpServers de 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.jsPara conectar su clon local a Claude Desktop sin publicar:
{
"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:devUna vez publicado, la imagen estará disponible en ghcr.io/lincalinca/crescender-mcp-server.
Sin caché de tokens en memoria: la validación llega a la API ascendente en cada llamada (la revocación es inmediata).
Sin estado en el sistema de archivos: solo stdout/stderr.
La configuración está basada en variables de entorno, se analiza una vez al inicio y se congela.
/health (cuando está habilitado) devuelve { ok, api_reachable, version } y sondea el /api/v1/health ascendente para verificar la accesibilidad, no solo "este proceso está vivo".
Apagado elegante: SIGTERM / SIGINT activan un drenaje de 30 segundos y luego fuerzan la salida.
Esto es lo que hace que el contenedor esté listo para k8s sin ningún código específico de k8s. Cuando finalmente se tome la decisión de orquestación (ASK / AKS / GKE / Fly / Railway / etc.), nada cambia aquí.
MIT: consulte LICENSE.
@crescender/crescender-core: la plataforma en sí, que sirve los endpoints /api/v1 que envuelve este MCP.
Especificación 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.
