Unofficial dubco-mcp-server
비공식 dubco-mcp-server
Dub.co 짧은 링크를 생성하고 관리하기 위한 모델 컨텍스트 프로토콜(MCP) 서버입니다(비공식). 이 서버를 통해 AI 어시스턴트는 Dub.co API를 통해 짧은 링크를 생성, 업데이트 및 삭제할 수 있습니다.
🚀 특징
Dub.co 도메인을 사용하여 사용자 정의 짧은 링크를 만드세요
기존 짧은 링크 업데이트
짧은 링크 삭제
모델 컨텍스트 프로토콜을 통한 AI 어시스턴트와의 원활한 통합
Related MCP server: MCP API Server
📋 필수 조건
Node.js 16.0.0 이상
API 액세스가 가능한 Dub.co 계정
Dub.co 대시보드 의 API 키
💻 설치
Smithery를 통해 설치
Smithery를 통해 Claude Desktop에 Dub.co MCP 서버를 자동으로 설치하는 방법:
지엑스피1
글로벌 설치
npm install -g dubco-mcp-server로컬 설치
npm install dubco-mcp-servernpx를 사용한 직접 사용
npx dubco-mcp-server⚙️ 구성
이 MCP 서버를 사용하려면 Dub.co API 키가 필요합니다. Dub.co 대시보드 에서 API 키를 받으실 수 있습니다.
API 키를 환경 변수로 설정합니다.
export DUBCO_API_KEY=your_api_key_here지속적인 구성을 위해 셸 프로필(예: .bashrc , .zshrc )에 다음을 추가합니다.
echo 'export DUBCO_API_KEY=your_api_key_here' >> ~/.zshrc🖥️ 커서 IDE 설정
Cursor IDE는 MCP 서버에 대한 기본 지원을 제공합니다. Cursor에서 dubco-mcp-server를 설정하려면 다음 단계를 따르세요.
1단계: 커서 IDE 설치
아직 다운로드하지 않았다면 Cursor IDE (버전 0.4.5.9 이상)를 다운로드하여 설치하세요.
2단계: 커서 설정 열기
커서 IDE 열기
왼쪽 하단 모서리에 있는 기어 아이콘을 클릭하거나 키보드 단축키
Cmd+,(Mac) 또는Ctrl+,(Windows/Linux)를 사용하세요.기능 섹션으로 이동
아래로 스크롤하여 "MCP 서버" 섹션을 찾으세요.
3단계: MCP 서버 추가
"+ 새 MCP 서버 추가"를 클릭하세요
나타나는 대화 상자에서:
이름 : "Dub.co MCP 서버"(또는 원하는 이름)를 입력하세요.
유형 : 드롭다운에서 "명령"을 선택하세요
명령어 :
env DUBCO_API_KEY=your_api_key_here npx -y dubco-mcp-server입력합니다(your_api_key_here실제 Dub.co API 키로 바꾸세요)
서버를 추가하려면 "저장"을 클릭하세요.
4단계: 연결 확인
MCP 서버를 추가하면 서버 이름 옆에 녹색 상태 표시기가 나타납니다. 빨간색이나 노란색 상태 표시기가 나타나면 다음을 시도해 보세요.
API 키가 올바른지 확인
커서 IDE 재시작
Node.js(16.0.0+)가 제대로 설치되었는지 확인
5단계: 서버 사용
dubco-mcp-server는 Cursor의 AI 기능과 함께 사용할 수 있는 도구를 제공합니다.
커서의 Composer 또는 Agent 모드를 엽니다(MCP는 이러한 모드에서만 작동합니다)
AI에게 Dub.co 도구(create_link, update_link, delete_link)를 사용하도록 명시적으로 지시합니다.
도구 사용 메시지가 나타나면 수락하세요.
🔧 MCP와 함께 사용
이 서버는 모델 컨텍스트 프로토콜(MCP)을 통해 AI 어시스턴트가 사용할 수 있는 도구를 제공합니다. MCP 호환 AI 어시스턴트와 함께 사용하려면 MCP 구성에 추가하세요.
MCP 구성 예
{
"mcpServers": {
"dubco": {
"command": "npx",
"args": ["-y", "dubco-mcp-server"],
"env": {
"DUBCO_API_KEY": "your_api_key_here"
},
"disabled": false,
"autoApprove": []
}
}
}사용 가능한 도구
링크 생성
Dub.co에 새로운 짧은 링크를 만드세요.
매개변수:
{
"url": "https://example.com",
"key": "optional-custom-slug",
"externalId": "optional-external-id",
"domain": "optional-domain-slug"
}예:
{
"url": "https://github.com/gitmaxd/dubco-mcp-server-npm",
"key": "dubco-mcp"
}업데이트_링크
Dub.co의 기존 짧은 링크를 업데이트합니다.
매개변수:
{
"linkId": "link-id-to-update",
"url": "https://new-destination.com",
"domain": "new-domain-slug",
"key": "new-custom-slug"
}예:
{
"linkId": "clwxyz123456",
"url": "https://github.com/gitmaxd/dubco-mcp-server-npm/releases"
}삭제_링크
Dub.co의 짧은 링크를 삭제합니다.
매개변수:
{
"linkId": "link-id-to-delete"
}예:
{
"linkId": "clwxyz123456"
}🔍 작동 원리
서버는 API 키를 사용하여 Dub.co API에 연결하고, AI 어시스턴트가 모델 컨텍스트 프로토콜(Model Context Protocol)을 통해 Dub.co와 상호 작용할 수 있는 표준화된 인터페이스를 제공합니다. 도구가 호출되면:
서버는 입력 매개변수를 검증합니다.
Dub.co API에 적절한 요청을 보냅니다.
응답을 처리하여 AI 어시스턴트가 이해할 수 있는 형식으로 반환합니다.
🛠️ 개발
소스에서 빌드
git clone https://github.com/gitmaxd/dubco-mcp-server-npm.git
cd dubco-mcp-server-npm
npm install
npm run build개발 모드에서 실행
npm run dev📝 라이센스
이 프로젝트는 ISC 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
🔗 링크
Dub.co - URL 단축 서비스
모델 컨텍스트 프로토콜 - MCP에 대해 자세히 알아보세요
👥 기여하기
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
저장소를 포크하세요
기능 브랜치를 생성합니다(
git checkout -b feature/amazing-feature)변경 사항을 커밋하세요(
git commit -m 'Add some amazing feature')브랜치에 푸시(
git push origin feature/amazing-feature)풀 리퀘스트 열기
👨💻 만든 사람
이 비공식 Dub.co MCP 서버는 GitMaxd (X에서는 @gitmaxd )에 의해 만들어졌습니다.
이 프로젝트는 모델 컨텍스트 프로토콜(MCP)과 MCP 서버 구축 방법을 이해하기 위한 학습 활동으로 개발되었습니다. Dub.co를 통합 대상으로 선택한 이유는 직관적인 API와 실용적인 활용성을 갖추고 있어 학습 프로젝트에 적합한 솔루션이었기 때문입니다.
Dub.co와 공식적인 제휴 관계는 없지만, 수동 및 자동 짧은 링크 생성 서비스 모두 강력 추천합니다. API는 문서화가 잘 되어 있고 사용하기 쉬워 이러한 유형의 통합에 적합합니다.
이 프로젝트가 도움이 되었거나 개선 제안 사항이 있으시면 언제든지 연락 주시거나 저장소에 기여해 주세요. 즐거운 링크 단축 되세요!
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.-