Unofficial dubco-mcp-server
Servidor dubco-mcp no oficial
Un servidor de Protocolo de Contexto de Modelo (MCP) para crear y gestionar enlaces cortos de Dub.co (no oficial). Este servidor permite a los asistentes de IA crear, actualizar y eliminar enlaces cortos mediante la API de Dub.co.
🚀 Características
Crea enlaces cortos personalizados con tus dominios Dub.co
Actualizar enlaces cortos existentes
Eliminar enlaces cortos
Integración perfecta con asistentes de IA a través del Protocolo de Contexto de Modelo
Related MCP server: MCP API Server
📋 Requisitos previos
Node.js 16.0.0 o superior
Una cuenta de Dub.co con acceso a la API
Una clave API del panel de Dub.co
💻 Instalación
Instalación mediante herrería
Para instalar Dub.co MCP Server para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @Gitmaxd/dubco-mcp-server-npm --client claudeInstalación global
npm install -g dubco-mcp-serverInstalación local
npm install dubco-mcp-serverUso directo con npx
npx dubco-mcp-server⚙️ Configuración
Este servidor MCP requiere una clave API de Dub.co para funcionar. Puede obtenerla desde el panel de control de Dub.co.
Establezca la clave API como una variable de entorno:
export DUBCO_API_KEY=your_api_key_herePara una configuración persistente, agregue esto a su perfil de shell (por ejemplo, .bashrc , .zshrc ):
echo 'export DUBCO_API_KEY=your_api_key_here' >> ~/.zshrc🖥️ Configuración del IDE del cursor
Cursor IDE ofrece compatibilidad nativa con servidores MCP. Siga estos pasos para configurar el servidor dubco-mcp en Cursor:
Paso 1: Instalar Cursor IDE
Si aún no lo ha hecho, descargue e instale Cursor IDE (versión 0.4.5.9 o posterior).
Paso 2: Abra la configuración del cursor
Abrir cursor IDE
Haga clic en el ícono de engranaje en la esquina inferior izquierda o utilice el atajo de teclado
Cmd+,(Mac) oCtrl+,(Windows/Linux).Vaya a la sección Características
Desplácese hacia abajo para encontrar la sección "Servidores MCP"
Paso 3: Agregar el servidor MCP
Haga clic en "+ Agregar nuevo servidor MCP"
En el cuadro de diálogo que aparece:
Nombre : Ingrese "Dub.co MCP Server" (o cualquier nombre que prefiera)
Tipo : Seleccione "comando" en el menú desplegable
Comando : Ingrese
env DUBCO_API_KEY=your_api_key_here npx -y dubco-mcp-server(Reemplaceyour_api_key_herecon su clave API de Dub.co real)
Haga clic en "Guardar" para agregar el servidor.
Paso 4: Verificar la conexión
Después de agregar el servidor MCP, debería ver un indicador de estado verde junto al nombre del servidor. Si muestra un estado rojo o amarillo, pruebe lo siguiente:
Comprobación de que su clave API es correcta
Reiniciando Cursor IDE
Verificar que Node.js (16.0.0+) esté instalado correctamente
Paso 5: Uso del servidor
El servidor dubco-mcp proporciona herramientas que se pueden utilizar con las funciones de inteligencia artificial de Cursor:
Abra el modo Compositor o Agente del cursor (MCP solo funciona en estos modos)
Instruya explícitamente a la IA para que utilice las herramientas de Dub.co (crear_enlace, actualizar_enlace, eliminar_enlace)
Acepte las indicaciones de uso de la herramienta cuando aparezcan
🔧 Uso con MCP
Este servidor proporciona herramientas que pueden usar los asistentes de IA mediante el Protocolo de Contexto de Modelo. Para usarlo con un asistente de IA compatible con MCP, añádalo a su configuración de MCP.
Ejemplo de configuración de MCP
{
"mcpServers": {
"dubco": {
"command": "npx",
"args": ["-y", "dubco-mcp-server"],
"env": {
"DUBCO_API_KEY": "your_api_key_here"
},
"disabled": false,
"autoApprove": []
}
}
}Herramientas disponibles
crear_enlace
Crea un nuevo enlace corto en Dub.co.
Parámetros:
{
"url": "https://example.com",
"key": "optional-custom-slug",
"externalId": "optional-external-id",
"domain": "optional-domain-slug"
}Ejemplo:
{
"url": "https://github.com/gitmaxd/dubco-mcp-server-npm",
"key": "dubco-mcp"
}enlace de actualización
Actualizar un enlace corto existente en Dub.co.
Parámetros:
{
"linkId": "link-id-to-update",
"url": "https://new-destination.com",
"domain": "new-domain-slug",
"key": "new-custom-slug"
}Ejemplo:
{
"linkId": "clwxyz123456",
"url": "https://github.com/gitmaxd/dubco-mcp-server-npm/releases"
}eliminar_enlace
Eliminar un enlace corto en Dub.co.
Parámetros:
{
"linkId": "link-id-to-delete"
}Ejemplo:
{
"linkId": "clwxyz123456"
}🔍 Cómo funciona
El servidor se conecta a la API de Dub.co usando su clave API y proporciona una interfaz estandarizada para que los asistentes de IA interactúen con Dub.co mediante el Protocolo de Contexto de Modelo. Al llamar a una herramienta:
El servidor valida los parámetros de entrada
Envía la solicitud apropiada a la API de Dub.co
Procesa la respuesta y la devuelve en un formato que el asistente de IA puede entender.
🛠️ Desarrollo
Construyendo desde la fuente
git clone https://github.com/gitmaxd/dubco-mcp-server-npm.git
cd dubco-mcp-server-npm
npm install
npm run buildEjecutando en modo de desarrollo
npm run dev📝 Licencia
Este proyecto está licenciado bajo la licencia ISC: consulte el archivo de LICENCIA para obtener más detalles.
🔗 Enlaces
Dub.co - El servicio de acortamiento de URL
Protocolo de Contexto Modelo - Más información sobre MCP
👥 Contribuyendo
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Bifurcar el repositorio
Crea tu rama de funciones (
git checkout -b feature/amazing-feature)Confirme sus cambios (
git commit -m 'Add some amazing feature')Empujar a la rama (
git push origin feature/amazing-feature)Abrir una solicitud de extracción
👨💻 Creado por
Este servidor MCP de Dub.co no oficial fue creado por GitMaxd ( @gitmaxd en X).
Este proyecto se desarrolló como un ejercicio de aprendizaje para comprender el Protocolo de Contexto de Modelo y cómo construir servidores MCP. Elegí Dub.co como objetivo de integración debido a su API sencilla y su utilidad práctica, lo que lo convierte en un candidato ideal para un proyecto de aprendizaje.
Aunque no tengo ninguna afiliación oficial con Dub.co, recomiendo ampliamente su servicio para la creación manual y automatizada de enlaces cortos. Su API está bien documentada y es fácil de usar, lo que la hace perfecta para este tipo de integración.
Si este proyecto te resulta útil o tienes sugerencias para mejorarlo, no dudes en contactarnos o contribuir al repositorio. ¡Feliz acortamiento de enlaces!
Available Tools
3 toolscreate_linkB
Create a new short link on dub.co, asking the user which domain to use
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The destination URL to shorten | |
| key | No | Optional custom slug for the short link. If not provided, a random slug will be generated. | |
| externalId | No | Optional external ID for the link | |
| domain | No | Optional domain slug to use. If not provided, the primary domain will be used. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions domain selection but fails to describe key traits like authentication requirements, rate limits, error handling, or what happens on success (e.g., returns a short URL). For a creation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by explicitly mentioning the required 'url' parameter or output expectations.
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 the complexity of a creation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return value (e.g., the generated short link), error conditions, or behavioral nuances like idempotency. This leaves gaps for an AI agent to invoke the tool correctly.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by hinting at domain selection ('asking the user which domain to use'), but doesn't provide additional syntax, format details, or context for parameters like 'key' or 'externalId'. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Create a new short link') and the resource ('on dub.co'), with a specific verb+resource combination. It distinguishes from siblings like 'delete_link' and 'update_link' by focusing on creation, though it doesn't explicitly contrast with 'upsert_link' which might have overlapping functionality.
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 usage when creating a short link on dub.co, with a hint about domain selection ('asking the user which domain to use'). However, it lacks explicit guidance on when to use this tool versus alternatives like 'upsert_link' or 'update_link', and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_linkC
Delete a short link on dub.co
| Name | Required | Description | Default |
|---|---|---|---|
| linkId | Yes | The ID of the link to delete |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a link, implying a destructive mutation, but doesn't mention whether this action is reversible, what permissions are required, how it affects associated data, or what happens on success/failure. For a destructive operation, this lack of detail is a significant gap, leaving the agent with insufficient information about behavioral traits.
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, direct sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the key verb 'Delete' and specifies the resource clearly. There's zero waste, making it easy for an agent to parse quickly while still being informative enough for basic understanding.
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 the tool's destructive nature (deletion), no annotations, and no output schema, the description is incomplete. It doesn't address critical context like what 'delete' entails (permanent vs. soft delete), error handling, or return values. For a mutation tool with zero annotation coverage, the description should provide more behavioral and outcome details to be sufficiently complete for safe agent use.
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 has 100% description coverage, with the single parameter 'linkId' clearly documented as 'The ID of the link to delete'. The description doesn't add any additional meaning beyond this, such as format examples or sourcing instructions. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra help from the description.
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 ('Delete') and resource ('a short link on dub.co'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'create_link' or 'update_link', but the verb 'Delete' inherently distinguishes it from creation and modification operations. The description is specific enough to understand what the tool does without being tautological.
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 provides no guidance on when to use this tool versus alternatives like 'update_link' or 'upsert_link'. It doesn't mention prerequisites (e.g., needing an existing link ID), error conditions, or typical use cases. While the action is clear, there's no context to help an agent decide between this and other link management tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_linkC
Update an existing short link on dub.co
| Name | Required | Description | Default |
|---|---|---|---|
| linkId | Yes | The ID of the link to update | |
| url | No | The new destination URL | |
| domain | No | The new domain for the short link | |
| key | No | The new slug for the short link |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention what permissions are required, whether changes are reversible, what happens to existing data not mentioned in parameters, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized and front-loaded with the essential information.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens when the update succeeds or fails, what permissions are needed, or how this differs from sibling tools. Given the complexity of updating database records and the lack of structured safety information, more context is needed.
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 description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
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 ('Update') and resource ('an existing short link on dub.co'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'upsert_link' which might also update links, leaving some ambiguity about when to choose one over the other.
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 provides no guidance on when to use this tool versus alternatives like 'upsert_link' or 'create_link'. It mentions 'existing short link' which implies a prerequisite that the link must already exist, but offers no explicit when/when-not instructions or comparison with sibling 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.
3 tool updates
v1.0.0- First observed
create_link - First observed
delete_link - First observed
update_link
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose targeting a specific CRUD operation on short links: create, delete, and update. There is no overlap or ambiguity between these actions, making it easy for an agent to select the correct tool based on the intended operation.
All tool names follow a consistent verb_noun pattern (create_link, delete_link, update_link) with uniform snake_case styling. This predictability enhances readability and reduces cognitive load for agents when scanning the toolset.
With only 3 tools, the set feels thin for a link management domain, as it lacks a 'get' or 'list' tool to retrieve existing links, which is a common and necessary operation. While the tools present are well-defined, the count is borderline low for practical use.
The toolset has significant gaps for a dub.co link management server. It covers create, update, and delete operations but omits retrieval tools (e.g., get_link, list_links), leaving agents unable to query existing links. This incompleteness will likely cause agent failures in workflows requiring read operations.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Short-link service embedded in your AI workflow — shorten links, track campaigns, read stats.
Related MCP Servers
- FlicenseAqualityDmaintenanceA Model Control Protocol server that enables Claude Desktop to interact with your self-hosted YOURLS URL shortener, allowing Claude to automatically shorten URLs, expand short URLs, and retrieve click statistics.14-
- AlicenseAqualityDmaintenanceA Model Context Protocol server that enables AI assistants to make HTTP requests (GET, POST, PUT, DELETE) to external APIs through standardized MCP tools.42MIT
- AlicenseNot gradedqualityDmaintenanceModel Context Protocol server that standardizes tool discovery, execution, and context management for AI applications.MIT
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server for Dub that enables creating, updating, deleting short links and retrieving link analytics through natural language.-