QuillBot Local MCP
# QuillBot Local MCP
Servidor MCP por STDIO, no oficial y experimental, para automatizar la interfaz web de QuillBot mediante Playwright. Devuelve texto del servicio y no modifica documentos.
**Estado: protocolo MCP probado; integración con el sitio real pendiente de validación.** Los selectores de la interfaz están vacíos intencionalmente. Después de instalar, `quillbot_status` funciona; detector y humanizador permanecerán bloqueados hasta configurar y comprobar sus controles reales. No es una integración lista para usar sin configuración. Los análisis hechos por separado desde un navegador no validan este adaptador.
## Requisitos e instalación
Node.js 22 o posterior y un cliente compatible con MCP por STDIO. La cuenta, suscripción y límites aplicables dependen de QuillBot.
```sh
git clone https://github.com/Disneik/quillbot-local-mcp.git
cd quillbot-local-mcp
npm ci
npx playwright install chromium
npm test
```
En Linux puede ser necesario `npx playwright install --with-deps chromium`. Consulte la [instalación oficial de Playwright](https://playwright.dev/docs/library).
Copie `settings.example.json` como `settings.json`:
```sh
# Linux / macOS
cp settings.example.json settings.json
```
```powershell
# PowerShell
Copy-Item settings.example.json settings.json
```
## Conectar un cliente MCP
Copie la entrada de `mcp.example.json` a la configuración MCP de su cliente. Sustituya ambas rutas absolutas por las de su copia local. En Windows se pueden utilizar barras `/`. `node` debe estar en el PATH del cliente; si no, indique su ruta absoluta. Los formatos de configuración pueden variar entre clientes.
La variable `QUILLBOT_SETTINGS` selecciona el archivo local. Si se omite, el servidor usa el ejemplo seguro incluido, con navegador deshabilitado. Para iniciar manualmente, use `npm start` (STDIO queda reservado para MCP).
## Configurar y validar QuillBot
1. Autorice el uso del navegador en su cliente o entorno. Este servidor abre su propio Chromium mediante Playwright y no hereda las restricciones técnicas del navegador del cliente.
2. En `settings.json`, active `browserAccessEnabled` únicamente si tiene esa autorización. Mantenga `verifiedAgainstLiveSite: false`.
3. Llame a `quillbot_inspect` con `{"mode":"detector","visible":true}`. Complete personalmente el inicio de sesión en la ventana si se solicita. Se usa un perfil propio; no se importan sesiones ni cookies de otros navegadores.
4. A partir de controles observados en la página, complete `editorSelector` (CSS), `submitButtonName` (nombre accesible exacto del botón) y `resultSelector` (CSS del resultado). `flaggedSelector` es opcional para pasajes señalados. Repita para `humanizer`. Las URLs iniciales pueden requerir ajustes si el servicio cambia.
5. Para efectuar una comprobación manual, habilite `verifiedAgainstLiveSite` y pruebe con un fragmento autorizado sin información sensible. Compare la entrada y salida con la página. Si la comprobación falla, vuelva a `false` y corrija la configuración antes de usarlo con otros textos.
Los selectores y el resultado dependen de la interfaz actual, del idioma y de la sesión. Un cambio en el DOM puede requerir una nueva validación. El servidor espera que el contenedor tenga texto diferente al anterior al envío; ese criterio no garantiza por sí solo que una respuesta parcial haya terminado ni que un resultado esté asociado a la entrada correcta. Compruébelo durante la validación. Si el servicio devuelve exactamente el mismo texto que antes, puede agotarse el tiempo de espera.
Para iniciar sesión de forma visible, haga la inspección visible antes de otra operación de navegador. Si ya existe un contexto oculto, reinicie el servidor primero. Las pestañas de inspección visible quedan abiertas para que el usuario pueda completar el acceso.
## Herramientas
| Herramienta | Uso |
| --- | --- |
| `quillbot_status` | Estado local, sin abrir el navegador ni enviar texto. |
| `quillbot_inspect` | Controles visibles, sin ejecutar detección; admite `mode` y `visible`. |
| `quillbot_detect` | Envía `text` al detector configurado y devuelve el resultado literal. |
| `quillbot_humanize` | Envía `text` al humanizador configurado y devuelve una propuesta para revisión editorial. |
Las respuestas contienen JSON breve, fecha, huella SHA-256 de la entrada y texto literal del servicio. No se infieren porcentajes adicionales. Solo se admite una operación simultánea. El límite local es de 30 000 caracteres por llamada; el límite real del servicio puede ser menor.
## Datos y límites
Las herramientas de detección y humanización envían el texto a QuillBot. El servidor no guarda los textos como informes, pero el cliente MCP y QuillBot pueden aplicar sus propias políticas de almacenamiento. El perfil `.browser-profile/` conserva la sesión: no lo comparta. `settings.json`, perfiles, informes y archivos de entorno quedan excluidos de Git.
No se incluyen claves, credenciales, cookies, textos de investigación ni documentos personales. No se automatizan CAPTCHA ni compras. Si hay un desafío, bloqueo, suscripción insuficiente o inicio de sesión pendiente, debe atenderlo el usuario. Los resultados del detector no certifican autoría y la paráfrasis necesita revisión del sentido, los datos y las citas; no se garantiza un resultado en Turnitin u otros servicios.
## Pruebas y contribuciones
`npm test` comprueba el protocolo STDIO, controles de acceso, destinos permitidos, resultados vacíos y exclusión mutua. Usa datos simulados identificados como tales; no inicia Chromium ni constituye una prueba contra QuillBot. Las contribuciones que configuren selectores deben documentar fecha, idioma y pasos de validación, sin aportar sesiones ni textos privados.
Implementado con el [SDK oficial de MCP](https://github.com/modelcontextprotocol/typescript-sdk) y [Playwright](https://playwright.dev/docs/library). Proyecto independiente, sin afiliación con QuillBot.
## Licencia
MIT. Consulte `LICENSE`.
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: status checks local adapter state, inspect validates visible controls/login readiness, detect runs AI detection, and humanize requests a rewriting proposal. Although status and inspect both relate to integration health, the descriptions cleanly separate them.
All tools follow the same predictable quillbot_ prefix with lowercase snake_case verbs/nouns: status, inspect, detect, humanize. There are no deviations or mixed conventions.
Four tools is well-scoped for a focused local QuillBot adapter. Each tool has a clear role in the workflow: health, validation/login, detection, and humanization.
The core detection and humanization operations are covered, along with status and integration validation. Minor lifecycle gaps remain, such as explicit session cleanup/logout, batch operations, or configuration tools, but agents can work around these.