Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Descripción del creador (original en inglés)
Local MCP server for requesting signatures from Agent-Q Firmware.
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
Elige la app de IA que usas y copia la configuración.
Necesitas
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Abre Claude Desktop → Settings → Developer → Edit Config y pega esto en claude_desktop_config.json
{
"mcpServers": {
"agent-q": {
"command": "npx",
"args": [
"-y",
"@stelis/agent-q"
]
}
}
}Ejecuta esto en tu terminal
claude mcp add agent-q -- npx -y @stelis/agent-qPégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json
{
"mcpServers": {
"agent-q": {
"command": "npx",
"args": [
"-y",
"@stelis/agent-q"
]
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Pégalo en .vscode/mcp.json de tu proyecto
{
"servers": {
"agent-q": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@stelis/agent-q"
]
}
}
}Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Este se ejecuta en tu computadora, y ChatGPT solo puede conectarse a servidores en internet. Elige otra app.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Se ejecuta en tu computadora; la lista de herramientas aparece en tu app de IA después de instalarlo.
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 6 nov 2026
El nombre en el registro se verificó con la cuenta de GitHub stelis-dev, dueña del repo
Todavía no hemos leído este repo en GitHub
Todavía no hemos leído este repo en GitHub
Este se ejecuta en tu computadora; no hay endpoint en internet
Se ejecuta en tu computadora y usa ajustes locales en su lugar
Se ejecuta en tu computadora; solo podemos leer listas de herramientas de endpoints en internet
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
El registro no indica ninguna clave obligatoria, aunque algunos servidores te piden iniciar sesión la primera vez que los usas.
Se ejecuta en tu computadora. Tu app de IA lo inicia cuando hace falta, y los datos no pasan por los servidores del creador (a menos que el propio servidor llame a un servicio en línea).
El repo de GitHub cambió por última vez –, y la última versión (0.2.2) llegó al registro hace 4 meses.
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. También necesitas Node.js en tu computadora.
En la misma categoría: Spec Driven Development, Remote Desktop Commander, Apify MCP Server
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Extract data from any website with thousands of scrapers, crawlers, and automations on Apify Store ⚡
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
Development status: Agent-Q is an active development project with
hardware-tested Sui signing paths for CLI, MCP, and supported provider flows.
The current StackChan CoreS3 Firmware path uses DEV_PROFILE material intended
for development and demos, not real-asset custody. See Current Status for
storage and profile limitations.
Agent-Q separates execution surfaces from signing authority.
Execution capability is not signing authority. Agent-Q keeps that boundary explicit for agent-driven and local Sui signing flows.
This README describes the Agent-Q authority-boundary architecture for local Sui signing flows. Current implementation status and profile limitations are tracked in docs/IMPLEMENTATION_STATUS.md.
MCP clients, Sui CLI, and supported Sui app adapters submit bounded requests through the local agent-q host process. AI agent runtimes usually reach Agent-Q through MCP clients. The host relays requests; it does not store signing material, decide policy, or approve signing.
Agent-Q Firmware runs on a separate signing device. It holds signing material and policy for the implemented material profile, checks device state and request contents, applies the implemented policy or device-local approval gate, and returns signed results or explicit failures.
Signing request transport stays local. Signing authority stays on the device. Requesters can ask for signatures, but they cannot hold signing material, choose the authorization mode, or approve their own requests.
Agent-Q has three roles:
agent-q process. It exposes MCP stdio tools, the local HTTP API, the Admin Page, and adapter-facing request surfaces, then relays bounded requests to Firmware.Agent-Q uses a simple authority model:
For signing requests, Firmware decides whether the implemented policy or device-local approval gate permits signing.
Unsupported chains and methods fail explicitly.
agent-q-sui-signer as a Sui CLI external signer. See packages/agent-q/README.md.packages/agent-q/README.md.packages/provider-sui/README.md and packages/sample-sui-dapp-kit/README.md.packages/sample-zklogin-test-web/README.md.firmware/README.md.| Package | Use it when you want to... |
|---|---|
@stelis/agent-q-core | discover devices, open sessions, call the Agent-Q protocol, and parse Firmware results. |
@stelis/agent-q | run the local MCP server, Admin Page, and agent-q-sui-signer. |
@stelis/agent-q-provider-sui | connect a Sui app to an Agent-Q device through a provider / Wallet Standard adapter. |
packages/sample-sui-dapp-kit | run a small dapp-kit sample that signs through Agent-Q. |
packages/sample-zklogin-test-web | run a non-production browser test tool for Sui zkLogin proof preparation/proposal and sign-only transaction checks through the Agent-Q browser provider over Web Serial. |
The current implementation includes these device-owned paths. They are development/demo capabilities; Current Status below defines the DEV_PROFILE and product-active limits.
sign_transaction supports inline txBytes and same-session staged payload delivery for larger Sui transaction bytes, up to the Sui serialized transaction maximum. This is a payload and adapter input capacity, not a claim that every Sui transaction shape is semantically signable; unsupported or unbindable shapes fail before signing.flowchart LR
Agent[AI agent] --> MCP[MCP API] Admin[Admin Page] --> HTTP[HTTP API] SuiCLI[Sui CLI] --> Signer[agent-q-sui-signer] App[Sui app] --> Provider[Sui provider]
MCP --> Server[agent-q local server] HTTP --> Server Signer --> Server Provider --> Server
Server --> Core[Agent-Q core] Core --> Firmware[Firmware]
Current signing routes are summarized below. In this README, product-active means the matching source, docs, tests, build, current-tree target hardware evidence, and visual evidence are complete in docs/IMPLEMENTATION_STATUS.md. A route can be implemented and hardware-tested while product-active evidence is still being completed.
| Chain | Method | Current behavior |
|---|---|---|
sui | sign_transaction | Current implementation supports inline or same-session staged Sui transaction bytes. It validates the request, parses bounded offline transaction facts when available, applies the device-local policy or user authorization gate, and produces a signature response only after that gate authorizes signing. The parsed sender must match the active account; the parsed gas owner must also match unless the active account's device-local Sui account setting accepts gas sponsors. Policy mode fails closed when required policy coverage is missing, incomplete, unmatched, or reject-matched. User mode shows covered offline facts only when Firmware can derive the required semantic facts and fit the required review details into its bounded display summary; parser success alone is not a clear-review guarantee. Otherwise it shows a device-local blind-signing warning for a valid transaction bound to the active account. Blind signing means confirming signable bytes whose transaction details are not fully reviewable from offline facts. |
sui | sign_personal_message | Current implementation supports bounded Sui personal-message signing in user authorization mode. Policy authorization mode fails closed for this method. |
The current implementation contains Sui zkLogin active identity paths, but docs/IMPLEMENTATION_STATUS.md does not mark them product-active. The sample test web exercises browser-to-device proof setup and sign-only transaction checks over Web Serial. Enoki, OAuth, prover work, and Google OAuth testnet setup stay in the browser test layer; Agent-Q receives only bounded proof proposals. The sample does not display JWTs or proof JSON and does not write them to browser storage.
Unsupported chains and unsupported methods fail explicitly. Chains are exposed through the shared protocol; Agent-Q does not create separate chain-specific product APIs.
This section explains who may request work and who may decide. DEV_PROFILE storage and product-active status are covered in Current Status.
Detailed status lives in docs/IMPLEMENTATION_STATUS.md.
Current implementation includes the Sui signing routes listed above, MCP tools, provider-sui, and StackChan CoreS3 Firmware paths. Hardware smoke coverage is recorded in docs/IMPLEMENTATION_STATUS.md; product-active signing support is claimed only when the matching status row says the source, docs, tests, build, hardware, and visual evidence are complete.
Current limitations:
specs/PROTOCOL.mddocs/SECURITY_MODEL.mddocs/STATE_MODEL.mddocs/POLICY_SCHEMA.mddocs/IMPLEMENTATION_STATUS.mdfirmware/README.mdfirmware/src/stackchan-cores3/README.mdInstall workspace dependencies:
npm install
Build all packages:
npm run build
Run the root test suite:
npm test
Firmware build instructions are target-specific. Start with firmware/README.md and the target README under firmware/src/ /.
.WORK/ is for local planning, scratch files, and investigation materials. It is not tracked by Git and must not be required by user-facing build or runtime instructions.