de en es ja ko ru zh

Quartermaster

Name: Quartermaster
Author: Tanshaydar

by Tanshaydar

Overview Schema Source Related Servers Discussions Admin

Python

Local

Quartermaster

License: MIT Release GitHub stars Python 3.10+ Platform

MCP Ready Search Vectors GUI Telemetry Tests PRs Welcome Inspired by

Este proyecto empezó porque quería prototipar una presa.

Nada serio: una demo corta, quizá algo más si funcionaba. Antes de construir nada, quería ver qué era lo que ya tenía y que pudiera acelerar el proceso. Así que busqué en mi biblioteca "presa": no apareció nada. Claro que no apareció nada: ningún activo se llama presa. Pero repartidas entre cuatro paquetes que ya poseía había mallas de hormigón curvado, un sistema de agua, algo de terreno rocoso. Todo lo que la presa necesitaba. Había tenido casi todo aquello durante años y nunca había conectado las piezas.

Eso es lo que te hacen ~1.500 activos repartidos entre dos tiendas. Casi todos de bundles y rebajas, y ninguno recordado. Y no es solo cosa mía: ningún asistente de IA lo sabe tampoco. Pídeles ayuda y o construyen todo desde cero o te mandan de compras, mientras cientos de dólares de exactamente lo que necesitas están en tu disco.

Quartermaster indexa toda tu biblioteca de Unity Asset Store y Fab localmente y se la sirve a tu agente de código a través de MCP. Es la herramienta que deseaba que existiera ese día: pregunta por una presa y te dicen que ya tienes mallas de hormigón curvado.

you    →  "I want to build a dam — what do I have to work with?"

agent  →  search_owned_assets(...)        finds the concrete meshes, water FX, terrain
          validate_stack([...])           checks none of them fight each other
          import_asset_to_project(...)    unpacks into Assets/, demos stripped

Cada resultado es algo que ya pagaste. Nada se inventa.

Quartermaster spotlight search

Escribir una descripción, no un nombre: ninguno de esos resultados comparte una palabra con la consulta.

¿Por qué Quartermaster?

El trabajo de un quartermaster nunca fue recordar lo que hay en las tiendas — es asegurarse de que estés equipado cuando llega el momento de moverse. Eso está más cerca del problema real que el olvido. No había perdido nada; sabía que poseía cosas. Lo que no podía hacer era pasar de "quiero prototipar una presa" a "abre estos cuatro paquetes" sin una hora de excavación antes — y quizá algo más si funcionaba no sobrevive a una hora de excavación. Las ideas que llegan así no se rechazan. Simplemente no llegan a ocurrir, y nunca averiguas si habrían funcionado.

Related MCP server: glade-mcp

La parte que nadie te cuenta

Ninguna de las dos tiendas admite lo que posees.

Unity eliminó /account/purchases (404 desde agosto de 2026). Fab no tiene API de propiedad, ni botón de exportación, ni nada. Tu historial de compras existe solo dentro de su GraphQL privado, tras SSO, MFA y detección de bots.

Conseguirlo requirió cuatro intentos, tres de ellos fallidos:

El Chromium incluido con Playwright — el captcha de Epic lo rechaza de plano ("habilita JavaScript").
Playwright manejando tu navegador real — inyecta hooks detectables; Epic lanza un segundo muro de seguridad después de la contraseña.
Depurador adjunto durante el inicio de sesión — el mismo resultado. Cualquier cosa que toque el flujo de inicio de sesión se marca.
Lo que realmente funciona: deja de automatizar por completo el inicio de sesión. Entras a través de una ventana de navegador normal — sin puerto de depuración, nada entre tú y la tienda — porque la automatización era en sí misma lo que disparaba los sistemas de riesgo. Solo después de que termines, en una sesión que estableciste tú mismo, Quartermaster adjunta un depurador y reproduce las consultas paginadas de la tienda — con sus propias cabeceras CSRF, su propio troceado (42 IDs por petición, porque eso es lo que envía el cliente de Unity).

Ese truco es la mayor parte de este proyecto. El resto — búsqueda, linting, desempaquetado — es sinceramente sencillo en comparación.

Dos reglas ganadas con esfuerzo e integradas en el diseño, por si alguna vez hackeas esto tú mismo:

Los navegadores deben cerrarse correctamente (taskkill sin /F). Un cierre abrupto pierde la cookie de confianza de dispositivo de Unity y te verás sometido a un desafío MFA en cada sesión futura.
Nunca ejecutes una descarga de biblioteca en modo headless. El modo headless activa el sistema de riesgo de Unity incluso con cookies válidas.

Lo que obtienes

Búsqueda que entiende intención y visión. Este es el problema de la presa.

Palabras clave exactas mediante SQLite FTS5.
Intención en lenguaje natural mediante embeddings de texto ONNX locales (BAAI/bge-small-en-v1.5) — "estructuras de hormigón para retener agua" saca a la superficie mallas y shaders cuyos listados nunca mencionan presas.
Comprensión visual cross-modal mediante embeddings CLIP ONNX (Qdrant/clip-ViT-B-32) — buscar "catedral gótica" puntúa literalmente tus capturas de pantalla y renders promocionales, encontrando activos incluso cuando sus descripciones de texto son completamente mudas. Las tres señales se fusionan con fusión de rango recíproco (RRF) de 3 vías en tu CPU. Sin GPU, sin proceso de base de datos vectorial, sin API en la nube — ONNX Runtime y una matriz numpy, en el mismo proceso que todo lo demás.

Medido en un almacén de ~1.800 activos: ~480 MB de RAM pico con ambos modelos residentes, ~1.5 s para la primera consulta (cargando BGE y CLIP), ~110 ms en caliente después. Los modelos se cargan de forma diferida, así que un agente que nunca busca nunca paga por ellos.

Datos reales sobre tu disco. Escanea %APPDATA%/Unity/Asset Store-5.x/ y el VaultCache de Epic para que cada resultado sepa si ya está descargado o es solo de nube. Los agentes prefieren lo local: una importación sin descargar nada supera a una de 4 GB.

Un linter para stacks. Dos renderizadores de vegetación se pelearán. Un módulo de MicroSplat sin el MicroSplat principal no hace nada en silencio. Un shader solo URP en un proyecto HDRP se renderiza en rosa. Quartermaster los detecta antes de que pases una tarde con ellos.

Desempaquetado directo. Extrae los archivos .unitypackage en caché directamente en Assets/, descartando /Demo/, /Samples/, /Documentation/ y PDFs de paso — normalmente entre un 60 y un 80 % menos de peso por paquete. Cada ruta declarada se normaliza y se verifica dentro de <project>/Assets/; los escapes son estructuralmente imposibles, no solo se filtran.

Instalación

El paquete independiente — descarga Quartermaster-windows-x64.zip desde Releases y descomprímelo en cualquier lugar. No se requiere Python.

Quartermaster.exe — GUI de escritorio con búsqueda spotlight Win+Alt+V, recolección de tiendas, navegación por la biblioteca y desempaquetado directo.
Quartermaster-mcp.exe — servidor MCP stdio independiente para Claude Desktop, Cursor, Antigravity y Windsurf.

Los datos de tu biblioteca viven de forma segura en %LOCALAPPDATA%\Quartermaster, así que las actualizaciones consisten en simples reemplazos de carpeta sin pérdida de datos.

Desde el código fuente — requiere Python 3.10+.

git clone https://github.com/Tanshaydar/Quartermaster.git
cd Quartermaster
pip install -r requirements.txt

Puebla tu biblioteca:

1. Inicia sesión. El único paso que te necesita. Se abre una ventana de navegador normal; la 2FA y los captchas se comportan exactamente como siempre. Ciérrala cuando termines y la sesión persiste localmente.

python -m src.store_client login unity
python -m src.store_client login fab

2. Recolecta y enriquece. De larga duración, reanudable y seguro de volver a ejecutar: cada uno continúa donde se detuvo.

python -m src.store_client fetch unity
python -m src.store_client fetch fab
python -m src.store_client enrich            # descriptions and cover art, politely batched
python -m src.store_client fab-deep-media    # Fab only: plain HTTP is 403'd, galleries need the authed browser

3. Construye los índices locales y luego escanea tu disco.

python -m src.semantic build     # text embeddings
python -m src.vision build       # screenshot embeddings + concept tagging
python -m src.local_scan         # which of them are already downloaded here

semantic build y vision build son lo que hace que "estructuras de hormigón para retener agua" y las consultas de concepto visual encuentren tus activos. Si los omites, la búsqueda sigue funcionando, pero solo con palabras clave exactas.

Ejecuta local_scan después de tener un catálogo, no antes. Si se escanea contra un almacén vacío, no tiene nada contra lo que comparar los nombres de archivo, así que archiva cada paquete en caché como su propia entrada simple. Inofensivo: el siguiente escaneo los concilia con el catálogo real, pero verás duplicados hasta entonces.

¿Ya tienes exportaciones CSV de las tiendas? Omite el navegador por completo:

python -m src.ingest             # eats any CSVs in data/seed/
python -m src.semantic build     # still needed — see the note above
python -m src.local_scan         # then find what's already on disk

Conecta tus agentes:

Opción A: Auto-registro (un comando)

# Standalone binary users:
Quartermaster-mcp.exe --register --all

# Source users:
python -m src.register --all             # Claude Desktop, Cursor, Windsurf, Antigravity
python -m src.register --all --dry-run   # look before you leap

El registro se fusiona con las configuraciones de cliente existentes y crea primero un .quartermaster-backup. No machacará tus otros servidores.

Opción B: Configuración manual Pega el bloque del servidor en la configuración de tu cliente:

Binario independiente:

{
  "mcpServers": {
    "quartermaster": {
      "command": "C:/path/to/Quartermaster/Quartermaster-mcp.exe",
      "args": []
    }
  }
}

Desde el código fuente:

{
  "mcpServers": {
    "quartermaster": {
      "command": "python",
      "args": ["-m", "src.mcp_server"],
      "cwd": "C:/path/to/Quartermaster"
    }
  }
}

Claude Desktop lee %APPDATA%/Claude/claude_desktop_config.json, Cursor ~/.cursor/mcp.json, Windsurf ~/.codeium/windsurf/mcp_config.json.

[!NOTE] Calentamiento del modelo en el primer uso: En la primera búsqueda de lenguaje natural o visión, los modelos de embeddings (BAAI/bge-small-en-v1.5 y clip-ViT-B-32) se descargan y se guardan en caché localmente mediante ONNX Runtime (~150 MB). La primera consulta puede tardar de 3 a 5 segundos mientras se carga en memoria; cada consulta posterior se ejecuta en ~100 ms.

Herramientas del agente

Herramienta	Respuestas
`search_owned_assets(query, ...)`	¿Qué tengo que encaje con esto? Híbrida: palabras clave + semántica.
`get_asset_details(asset_id)`	Metadatos completos, notas de uso, galería, URL de la tienda.
`get_stack_recommendations(brief)`	Asigna un brief de funcionalidad a paquetes que posees.
`validate_stack(asset_ids)`	¿Se pelearán entre sí? Conflictos de rol, prerrequisitos faltantes.
`list_stack_recipes()`	Stacks de producción seleccionados resueltos contra tu biblioteca.
`audit_project(project_dir)`	Motor, versión y pipeline de renderizado de un proyecto objetivo.
`import_asset_to_project(asset_id, project_dir)`	Desempaqueta un paquete local en `Assets/`.
`list_asset_categories()`	Desglose de categorías y recuentos.
`get_vault_stats()`	Totales por motor y categoría, local vs nube.

Dos archivos te permiten enseñar a Quartermaster tu propio vocabulario, sin necesidad de cambios de código:

data/recipes.json — roles, prerrequisitos y stacks seleccionados. Esto es con lo que razona el linter de conflictos: qué activos compiten por el mismo trabajo, qué necesita qué, y qué combinaciones consideras un stack de probada eficacia.
data/concepts.json — el vocabulario visual contra el que CLIP puntúa tus capturas de pantalla. La lista incluida está pensada para juegos; si haces archviz o previs, reemplázala y reconstruye.

Ambos son JSON plano que se lee en tiempo de ejecución, y ambos tienen una página de referencia en docs/.

Otras formas de entrar

Aplicación de escritorio (run_desktop.bat) — búsqueda spotlight PySide6 con icono en la bandeja; pulsa Win+Alt+V en cualquier lugar de Windows. Se ejecuta junto a tu agente sin estorbar: la base de datos funciona en modo WAL, así que la GUI escribiendo mientras tu agente busca no bloquea a ninguno de los dos.
Interfaz web (run_ui.bat) — panel en modo oscuro en http://localhost:7890.
En Unity — importa editor_bridge/Quartermaster-Bridge.unitypackage y luego Window > Quartermaster. Busca e importa sin salir del editor. Pequeño inciso: ese paquete puente lo genera src/build_bridge.py, que escribe el mismo formato tar que lee unpacker.py. Dogfooding a propósito.

Seguridad

Esta cosa guarda las sesiones de las tiendas y escribe en tus proyectos, así que se toma la API local en serio:

Cada endpoint que modifica el estado requiere un token (generado en la primera ejecución, almacenado en data/.auth_token, replicado para el puente de Unity). Envíalo como X-Quartermaster-Token o Authorization: Bearer; la interfaz web recibe automáticamente una cookie SameSite=Strict.
Las peticiones de origen cruzado se rechazan incluso con un token válido.
El sandbox del desempaquetador colapsa los segmentos .., elimina las letras de unidad y los caracteres de control, reubica cualquier cosa que esté fuera de Assets/ en Assets/_Quartermaster_Imported/ y garantiza que la ruta final quede dentro del proyecto — respaldado por pruebas, no por corazonadas (python run_tests.py -v).
El proxy de imágenes se limita a una lista blanca de dominios, bloquea rangos privados y endpoints de metadatos, revalida cada salto de redirección, limita los tamaños y poda las entradas más antiguas cuando la caché supera su límite de archivos.

Nada llama a casa. Tu biblioteca, los embeddings, las rutas de disco y las sesiones de las tiendas permanecen en esta máquina.

Configuración

Claves opcionales en config.json (creado en la primera ejecución):

Clave	Predeterminado	Propósito
`server_port`	`7890`	Puerto de la interfaz web / API.
`embedding_model`	`BAAI/bge-small-en-v1.5`	Cualquier modelo compatible con fastembed. Cámbialo y reconstruye el índice.
`fab_vault_dirs`	Detección automática	Sobrescribe las ubicaciones de VaultCache de Fab.
`strip_dirs` / `strip_exts`	demos, docs, PDFs	Lo que descarta el desempaquetador.
`enrich_batch_size` / `enrich_batch_pause`	`20` / `3s`	Limitador de cortesía para el enriquecimiento.
`media_cache_enabled`	`true`	Caché en disco para las carátulas servidas mediante proxy.

Limitaciones honestas

Windows primero. El escaneo de caché asume rutas de Windows. La búsqueda MCP funciona en cualquier parte; la detección de importación local, no.
Una máquina, un usuario. Sin sincronización, sin modo servidor. Deliberado.
La recolección es scraping. Unity y Fab cambian sus internals cuando les place, y de hecho ya lo han hecho — los tamaños de chunk, los endpoints y las formas GraphQL que hay aquí eran correctos el día en que lo publiqué, no para siempre. Cuando una descarga vuelve vacía, data/store_harvest.log registra cada respuesta JSON vista; ahí es donde empezar a investigar.
La taxonomía es heurística. Las categorías se infieren mediante una combinación multimodal de tokens de límite de palabra, etiquetas de la tienda y minería de conceptos visuales CLIP zero-shot a partir de capturas de pantalla. Los títulos muy estilizados sin capturas de pantalla se asignan por defecto a Tools & Utilities, aunque la búsqueda vectorial semántica y la búsqueda híbrida siempre cubren el vault completo, independientemente de la categoría asignada. El ajuste del vocabulario visual está documentado en docs/concepts.md.
La indexación se detiene en el límite del paquete y los metadatos de la tienda son ruidosos. La búsqueda opera sobre títulos, descripciones, etiquetas y embeddings CLIP de imagen completa de las capturas de la galería. Se enfrenta a dos límites estructurales:
1. Sin indexación de activos internos: No desempaqueta el contenido de los archivos comprimidos para indexar sub-mallas, prefabs o nombres de archivo internos individuales (p. ej., buscar un subelemento arquitectónico concreto como una «teja árabe» o una «contrahuella de hormigón curvo» dentro de un paquete de entorno modular no dará resultados a menos que se declare en el texto del listado o sea prominente en los renders de la galería).
2. Texto de plantilla vacío de la tienda: Una fracción notable de los listados de la tienda (en particular el og:description con plantilla de Unity) contiene texto de marketing puro ("Elevate your workflow with...") que no aporta ninguna información técnica. Los embeddings CLIP visuales existen precisamente para salvar esta brecha, pero los vectores de imagen completa no siempre pueden resolver subelementos de grano fino.
El desempaquetado es solo para Unity. Los activos de Fab se indexan y son buscables, pero la extracción de .unitypackage obviamente no aplica.

Cuando se rompe

Abre un issue. Es un proyecto en solitario, así que no puedo prometer un tiempo de respuesta, pero sí los leo.

Lo que ayuda, según el síntoma:

Una descarga volvió vacía o incompleta. Es lo que tiene más probabilidades de romperse, porque las tiendas cambian sus internals sin previo aviso. data/store_harvest.log registra cada respuesta JSON que vio la recolección — la cola de ese archivo es el diagnóstico completo. Inclúyela.
La búsqueda no devuelve nada sensato. Comprueba primero python -m src.vision status. Un índice sin construir degrada en silencio la búsqueda a solo palabras clave, y eso explica la mayoría de los informes de «la búsqueda está rota».
Categorías incorrectas, o un conflicto que no es real. Eso suele ser la base de conocimiento, más que el código — docs/recipes.md y docs/concepts.md explican cómo arreglarlo tú mismo, y un PR a data/recipes.json con una regla para la que no tengo los activos necesarios para probarla es genuinamente bienvenido.
La aplicación independiente no arranca. Es --windowed, así que falla en silencio. %LOCALAPPDATA%\Quartermaster\data\crash.log es donde va a parar.

Si construyes algo chulo con esto, de verdad me gustaría saberlo.

Nota sobre las tiendas

Quartermaster lee tu propia cuenta, desde tu propia máquina, en un navegador en el que has iniciado sesión tú mismo. No guarda credenciales, no envía nada a ningún servidor mío y no tiene telemetría — la sesión vive en un perfil de navegador local y la biblioteca en un archivo SQLite local. No hay ningún backend compartido que pueda filtrarse.

No está afiliado a Unity Technologies ni a Epic Games, no cuenta con su respaldo ni tiene conexión con ellas. Unity, Unity Asset Store, Fab y Unreal Engine son marcas comerciales de sus respectivos propietarios. Automatizar el acceso a cualquier servicio es una decisión que debes tomar tú conforme a los términos de ese servicio, y esta herramienta no la toma por ti.

Licencia

MIT. Consulta LICENSE.

Available Tools

9 tools

audit_projectA

Detect the engine, version and render pipeline of a game project (Unity: from ProjectVersion.txt / manifest.json; Unreal: .uproject / DefaultEngine.ini). Call this BEFORE recommending or importing assets so pipeline mismatches (e.g. URP-only shader into an HDRP project) are caught.

ParametersJSON Schema

Name	Required	Description	Default
`project_dir`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. The verb 'Detect' strongly implies a read-only operation; however, it does not explicitly state that no modifications or side effects occur. The description gives sufficient functional context but stops short of stating non-destructive behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences that deliver purpose and usage without fluff. The parenthetical examples add useful specificity without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description covers the essential context: what it detects, when to use it, and why it matters (avoiding pipeline mismatches). It does not describe the return format, but that is not critical for a detection tool and the output schema exists separately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, project_dir, is not elaborated in the description at all. While the name suggests a file path, there is no mention of expected format, whether it should point to a root folder or a specific file, or any related constraints. With 0% schema coverage, the description should compensate but does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Detect') and resource ('engine, version and render pipeline of a game project'). It distinguishes itself from sibling tools by focusing on detection rather than mutation or retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs when to use the tool: 'Call this BEFORE recommending or importing assets.' This provides a direct usage trigger and sets expectations for preconditions, leaving no ambiguity about when it should be invoked.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_asset_detailsB

Full details for one owned asset: summary, usage notes, gallery/video links, store URL.

ParametersJSON Schema

Name	Required	Description	Default
`asset_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It conveys a read-only lookup and previews the output fields, but it does not disclose failure modes, authorization/ownership consequences, or any limitations. It is minimally adequate for a simple getter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; every phrase contributes either scope ('one owned asset') or expected content. Exemplary concision for a simple lookup.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return-value structure, so the description doesn't need to restate it, and the one-parameter tool is simple. However, the description omits when to use the tool versus its siblings and leaves parameter semantics underspecified, so it is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the lone asset_id parameter is never defined, formatted, or tied to the description beyond the phrase 'one owned asset.' The description does not compensate for the missing parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource ('one owned asset') and enumerates the returned content ('summary, usage notes, gallery/video links, store URL'). It does not use an explicit verb beyond the tool name, and the contrast with siblings like search_owned_assets is only implicit, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'One owned asset' implies this is for retrieving details on a specific already-known asset rather than searching across assets, but the description never explicitly says when to prefer it over search_owned_assets or other siblings. Usage context is implied, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_stack_recommendationsA

Given a game/feature description (e.g. 'third-person fantasy open world with magic combat and a village'), sweep the vault using 3-way hybrid search (FTS + BGE + CLIP) and recommend which owned packages fit which aspect of the problem.

ParametersJSON Schema

Name	Required	Description	Default
`limit_per_category`	No
`problem_description`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations available, the description carries the full burden and does disclose meaningful behavior: it performs a 3-way hybrid search (FTS + BGE + CLIP) and returns recommendations mapped to aspects of the problem. It does not explicitly mention side effects, permissions, or non-mutation, but 'recommend' strongly implies a read-only sweep.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense, well-structured sentence. It front-loads the input and purpose, includes a useful example, and adds meaningful algorithmic detail without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main input, the search approach, and the intent of the output, and the output schema can explain return values. However, it omits the semantics of limit_per_category and provides no guidance on how this tool compares to sibling search/recommendation tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description gives clear semantics for problem_description, including a concrete example, but says nothing about limit_per_category. With schema description coverage at 0%, the optional parameter's meaning is left entirely to inference from its title and default value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: it sweeps the vault via hybrid search and recommends owned packages for a given game/feature description. It is distinct in behavior from siblings like search_owned_assets, though it does not explicitly name or contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied: provide a game/feature description to get package recommendations. However, it does not state when to prefer this tool over search_owned_assets or other sibling tools, nor does it provide any exclusions or alternative conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_vault_statsA

Overall vault stats: total assets per engine, per category, and how many are already downloaded locally vs cloud-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the behavioral disclosure burden. It discloses the nature of the output in useful detail: totals per engine, per category, and download status breakdown. Being a read-only stats endpoint, this is sufficient transparency, though it does not explicitly state that no mutation occurs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every phrase adds concrete information about the aggregation dimensions and the local-versus-cloud distinction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter aggregate stats tool with an output schema present, the description tells the agent exactly what dimensions the stats cover. Nothing crucial is missing for selecting or invoking this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so parameter semantics are inherently non-issue. The baseline of 4 applies, and the description correctly implies that the tool operates over the entire vault without requiring arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies a specific resource (vault) and the kind of output (overall stats), listing concrete aggregation dimensions: assets per engine, per category, and local vs cloud-only counts. It implies a broad overview role among the siblings, though it does not explicitly name an alternative to distinguish itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Overall vault stats' signals that this tool is for high-level aggregate information rather than per-asset or per-category detail, so usage context is implied. However, there is no explicit statement of when to use this tool versus siblings like get_asset_details or list_asset_categories, and no exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

import_asset_to_projectA

Unpack a locally-downloaded Unity Asset Store package (.unitypackage) directly into a Unity project's Assets/ folder. Only works for assets tagged local=true (check with search first). project_dir must be the Unity project root (the folder containing Assets/). A UPM package shipped inside it (Packages// with a package.json) is installed as an embedded package in /Packages// and listed in embedded_packages.

ParametersJSON Schema

Name	Required	Description	Default
`asset_id`	Yes
`project_dir`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does disclose real traits: the local=true restriction, the required shape of project_dir, and the non-obvious side effect of installing a bundled UPM package as an embedded package in <project>/Packages/<name>/. It does not mention overwrite/reversibility or permissions, so it is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action and constraint. The embedded-package sentence is dense but adds genuinely useful behavior rather than restating the schema, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is unnecessary, and the description still flags embedded_packages as a notable output signal. For a write tool with no annotations, it should ideally note overwrite behavior or failure modes, but the essentials for correct invocation are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: project_dir is explained as the project root (the folder containing Assets/), and asset_id is tied to the local=true tagging rule. The two parameters are semantically covered, though asset_id format is not specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: unpack a locally-downloaded .unitypackage directly into a Unity project's Assets/ folder. It implicitly separates this from the discovery siblings by noting that search comes first, so an agent can tell it apart from search_owned_assets and get_asset_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states an explicit precondition (only assets tagged local=true) and routes the agent to check with search first, which maps to the search sibling. It does not state when NOT to use it or what happens on a non-local asset beyond 'only works', leaving a small gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_asset_categoriesA

List all categories and how many owned assets fall into each.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral burden. The verb 'List' implies a read-only operation and the description states the output shape, but it does not disclose potential nuances such as whether categories with zero assets are included, ordering, or data freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with the action and resource, containing no redundant or filler information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters and an output schema present, the description fully covers what an agent needs to invoke the tool correctly. There is no need to explain return values because the output schema already exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no semantic ambiguity to clarify. The baseline of 4 applies because there are no parameters at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('categories'), and clearly states the output: how many owned assets fall into each category. This distinguishes it from siblings like search_owned_assets or get_vault_stats, which target different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives, no mention of scenarios that favor a sibling, and no exclusions or prerequisites. An agent must infer usage solely from the name and the literal description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_stack_recipesA

Curated production stacks ('asset recipes') resolved against the user's OWN library. Each recipe lists which owned assets fill each slot.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool is personalized by resolving against the user's OWN library and explains the output shape: each recipe lists which owned assets fill each slot. This gives meaningful behavioral context beyond the tool name, though it does not explicitly state side-effect absence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. It front-loads the core purpose and immediately clarifies the key distinguishing behavior and return format, making every sentence informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no annotations, and an existing output schema, the description is complete enough for an agent to invoke the tool correctly. It defines the resource, the personalization scope, and what each returned recipe contains, so no critical operational detail is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the baseline is 4. The description adds value by indicating that the user context is implicit and that results are scoped to the user's own library, which is the relevant semantic context despite the empty parameter list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('list') and a clear resource ('curated production stacks' / 'asset recipes'), then clarifies the differentiating scope: they are resolved against the user's OWN library. This distinguishes it from siblings like get_stack_recommendations and search_owned_assets by emphasizing curated, owned-asset-specific recipes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when the user wants curated recipes resolved against their own library rather than generic recommendations or raw asset search. However, it does not explicitly state when-not-to-use it or name any sibling alternative, so usage guidance is inferred rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_owned_assetsA

Search the user's asset vault across Unity, Fab, Quixel Megascans, Gumroad, and Cosmos. Hybrid: keyword (FTS5) fused with BGE text embeddings and CLIP visual vectors via 3-way RRF. Results include 'match' attribution ('keyword+semantic+vision') and 'ownership' ('vault_owned' vs 'catalog_grant').

engine: target game engine compatibility (all|unity|unreal|godot). Engine-agnostic sources (Quixel FBX/textures, Cosmos) match both unity and unreal.
source: filter by marketplace provider (all|unity|fab|quixel|gumroad|cosmos).
pipeline: render pipeline (all|HDRP|URP|Built-in).
local_only: only assets already downloaded to disk.
limit: max results to return.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`engine`	No	all
`source`	No	all
`category`	No	all
`pipeline`	No	all
`local_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full behavioral burden and delivers substantive traits: the 3-way RRF fusion of FTS5/BGE/CLIP, result 'match' attribution ('keyword+semantic+vision'), and the ownership distinction ('vault_owned' vs 'catalog_grant'). It also discloses engine-agnostic matching behavior for Quixel and Cosmos sources. It stops short of pagination, rate limits, and error behavior, but the core result-interpretation behaviors are well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose line is front-loaded, followed by two compact behavioral notes, then a terse parameter block where each line earns its place with inline enums. No filler, no repetition of schema defaults. The structure is scannable and information-dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return structure, so the description rightly focuses on filtering semantics and result interpretation. For a 7-parameter hybrid-search tool with zero annotations, it covers the essentials: marketplaces, engine-agnostic matching, render pipeline, and ownership/match attribution. Remaining gaps—query syntax, pagination beyond limit, and empty-result behavior—are modest for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for 5 of 7 parameters: engine, source, pipeline, local_only, and limit all receive meaningful semantics with inline enum values (e.g., 'all|unity|fab|quixel|gumroad|cosmos'). The engine note adds genuine nuance ('Engine-agnostic sources... match both unity and unreal'). query and category remain unexplained, with query—the only required parameter—lacking any guidance on accepted query syntax.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Search the user's asset vault across Unity, Fab, Quixel Megascans, Gumroad, and Cosmos.' The enumerated marketplaces and the vault scope clearly distinguish it from siblings like get_asset_details, list_asset_categories, and get_vault_stats. The hybrid-search detail ('keyword (FTS5) fused with BGE text embeddings and CLIP visual vectors') reinforces that this is the vault search operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than explicit: the name and first line mark this as the vault search tool, and filters like local_only ('only assets already downloaded to disk') hint at concrete use cases. However, the description never states when to prefer this over siblings (e.g., get_asset_details for a known asset, list_asset_categories for taxonomy) or any exclusion conditions. An agent must infer the division of labor from sibling names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_stackA

Lint a set of owned assets that are planned for one project/stack. Detects role conflicts (two weather systems, two vegetation renderers, …), same-product family notes, and missing prerequisites (e.g. MicroSplat module without core MicroSplat). Call before importing multiple assets together.

ParametersJSON Schema

Name	Required	Description	Default
`asset_ids`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. 'Lint' and 'detects' imply a non-mutating validation pass, and the specific detection categories explain what the tool does. It does not explicitly state side-effect freedom or permission requirements, but the language strongly signals read-only analysis for a pre-import check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: purpose, concrete detection examples, and a single usage directive. The most important information is front-loaded, and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single input parameter, no annotations, and an existing output schema, the description covers purpose, input semantics, and when to call it. It could explicitly confirm that no changes are made or name sibling alternatives, but it leaves no major workflow ambiguity for a validation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the only parameter, asset_ids, has an empty items schema. The description compensates by clarifying that these are 'owned assets planned for one project/stack,' and the plural usage plus 'importing multiple assets' conveys that all intended assets should be passed together.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Lint a set of owned assets that are planned for one project/stack.' It also enumerates concrete outputs (role conflicts, family notes, missing prerequisites), which makes it clearly distinct from siblings like get_stack_recommendations or audit_project without requiring schema inspection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit invocation context: 'Call before importing multiple assets together.' It does not name alternative tools or exclusion conditions, but the workflow placement is clear enough for an agent to choose this over search, recommendation, or import tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv1.3.0Sep 8, 2026
- First observedaudit_project
- First observedget_asset_details
- First observedget_stack_recommendations
- First observedget_vault_stats
- First observedimport_asset_to_project
- First observedlist_asset_categories
- First observedlist_stack_recipes
- First observedsearch_owned_assets
- First observedvalidate_stack

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.9/5.0

Scored 2026-09-30 05:50 across 9 tools

Disambiguation4/5

Most tools have clearly distinct purposes: auditing a project, searching assets, importing assets, validating stacks, and retrieving stats. The main overlap is among the stack-oriented tools (get_stack_recommendations, list_stack_recipes, validate_stack), but their descriptions distinguish recommendation, curation, and linting roles well enough for an agent to choose correctly.

Naming Consistency5/5

All tool names use consistent snake_case with clear verb_noun patterns (audit_project, list_asset_categories, get_asset_details, search_owned_assets, validate_stack, etc.). There is no mixing of camelCase or inconsistent verb styles.

Tool Count5/5

Nine tools is well-scoped for an asset vault and project-integration server. Each tool earns its place, covering discovery, inspection, recommendation, validation, and import without excessive breadth.

Completeness4/5

The surface covers core workflows: project audit, asset search/details, category/stats overview, stack recommendation/validation, and Unity import. Minor gaps exist, such as no Unreal/Fab import path and no explicit asset removal or metadata update operation, but agents can work around these for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcpOAuth
ai.zine
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Knowledge & Memory RAG Systems Autonomous Agents
2
Gessa: game asset generation for AI agentsOAuth
ai.gessa
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
AI & Machine Learning Image & Video Processing Audio Processing
1
khiveOAuth
ai.khive
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Knowledge & Memory Project Management
1
memsprout AOAuth
com.memsprout
shared AI-context layer for teams — persistent memory your agents search and update over MCP
Knowledge & Memory RAG Systems
2

Related MCP Servers

unity-mcp
Developer Tools Code Analysis Knowledge & Memory
verysleepylemon
A
license
Not graded
quality
D
maintenance
The first Model Context Protocol server for Unity projects. It gives AI assistants real understanding of Unity scenes, prefabs, and C# scripts through a queryable knowledge graph.
Updated 7 months ago (2026-04-06 02:32 UTC)
15 npm
1
MIT
glade-mcpofficial
Developer Tools AI & Machine Learning
Glade-tool
A
license
Not graded
quality
A
maintenance
Connect any MCP-compatible AI client (Claude Code, Cursor, Windsurf) to Unity or Godot. 300+ granular tools, an editor aware system prompt, game design document project context, script semantic search, and skill calibration.
Updated 2 months ago (2026-09-02 19:58 UTC)
212
MIT
unity-biome-mcp
Developer Tools Games & Gamification Testing & QA Tools
german-krasnikov
A
license
A
quality
A
maintenance
MCP server for controlling the Unity Editor from AI clients. 140+ tools for scenes, GameObjects, components, assets, Shader Graph, PlayTest DSL, screenshots with visual diff, batch operations with Undo rollback, and in-editor chat. Token-efficient plain-text protocol.
Updated 8 days ago (2026-10-13 22:06 UTC)
36
31
MIT
game-dev-resource-mcp
Games & Gamification Open Data Search
dsaewkfiush03-debug
A
license
A
quality
B
maintenance
License-aware game development resource discovery MCP server. Helps AI coding agents find reusable game assets with commercial-use filtering, license classification, and attribution generation.
Updated 21 days ago (2026-09-30 12:34 UTC)
9
1
MIT

Quartermaster

¿Por qué Quartermaster?

La parte que nadie te cuenta

Lo que obtienes

Instalación

Herramientas del agente

Otras formas de entrar

Seguridad

Configuración

Limitaciones honestas

Cuando se rompe

Nota sobre las tiendas

Licencia

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

glade-mcpofficial