AI 파이프라인을 위한 품질 관리 — 단일 MCP 도구. Claude Code, Claude Desktop 및 모든 MCP 클라이언트와 호환됩니다.
팀의 29.5%는 AI 결과물에 대한 평가를 전혀 수행하지 않습니다. (LangChain 설문조사) 지식 노동자는 매주 4.3시간을 AI 결과물 사실 확인에 소비합니다. (Microsoft 2025)
AgentDesk MCP가 이를 해결합니다. 30초 만에 모든 AI 파이프라인에 독립적인 적대적 검토 기능을 추가하세요.
npx @ezark-publish/agentdesk-mcpclaude mcp add agentdesk-mcp -- npx @ezark-publish/agentdesk-mcp{
"mcpServers": {
"agentdesk-mcp": {
"command": "npx",
"args": ["-y", "@ezark-publish/agentdesk-mcp"],
"env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
}
}
}원격 액세스, Smithery 호스팅 또는 다중 클라이언트 설정을 위해 HTTP 서버로 실행하세요:
# Start with HTTP transport on port 3100
MCP_HTTP_PORT=3100 npx @ezark-publish/agentdesk-mcp
# Or use the --http flag (defaults to port 3100)
npx @ezark-publish/agentdesk-mcp --httpMCP 엔드포인트: POST http://localhost:3100/mcp
상태 확인: GET http://localhost:3100/health
npm install github:Rih0z/agentdesk-mcpANTHROPIC_API_KEY 환경 변수 (사용자 본인의 키 사용 — BYOK)
Related MCP server: open-code-review
review_outputAI가 생성한 모든 결과물에 대한 적대적 품질 검토. 독립적인 검토자가 작성자가 실수를 저질렀다고 가정하고 적극적으로 문제를 찾습니다.
입력:
매개변수 | 필수 | 설명 |
| 예 | 검토할 AI 생성 결과물 |
| 아니요 | 사용자 지정 검토 기준 |
| 아니요 | 카테고리: |
| 아니요 | 검토자 모델 (기본값: |
출력:
{
"verdict": "PASS | FAIL | CONDITIONAL_PASS",
"score": 82,
"issues": [
{
"severity": "high",
"category": "accuracy",
"description": "Claim about X is unsupported",
"suggestion": "Add citation or remove claim"
}
],
"checklist": [
{
"item": "Factual accuracy",
"status": "pass",
"evidence": "All statistics match cited sources"
}
],
"summary": "Overall assessment...",
"reviewer_model": "claude-sonnet-4-6"
}review_dual이중 적대적 검토 — 두 명의 독립적인 검토자가 서로 다른 관점에서 결과물을 평가한 후, 병합 에이전트가 결과를 종합합니다.
검토자 중 한 명이라도 치명적인 문제를 발견하면 → 병합된 판정은 FAIL(실패)
더 낮은 점수를 채택
모든 문제를 결합하고 중복 제거
품질이 중요한 고위험 결과물에 사용하세요.
review_output과 동일한 매개변수를 사용합니다.
적대적 프롬프팅: 검토자는 실수가 있었다고 가정하도록 지시받습니다. 의심의 여지를 두지 않습니다.
증거 기반 체크리스트: 모든 PASS 항목은 구체적인 증거를 요구합니다. 증거가 없는 항목은 자동으로 FAIL로 강등됩니다.
게임화 방지 검증: 체크리스트 항목의 30% 이상에 증거가 부족하면, 전체 검토는 50점으로 제한된 FAIL 판정을 받습니다.
구조화된 출력: 판정 + 숫자 점수 + 분류된 문제 + 체크리스트 (단순히 "좋아 보임"이 아님).
코드 검토: 버그, 보안 문제, 성능 문제 확인
콘텐츠 검토: 정확성, 가독성, SEO, 대상 적합성 확인
사실 확인: AI 생성 텍스트의 주장 검증
번역 품질: 정확성 및 자연스러움 확인
데이터 추출: 완전성 및 정확성 확인
모든 AI 결과물: 요약, 보고서, 제안서, 이메일 등
자기 검토에는 체계적인 관대함 편향이 있습니다. 자신의 결과물을 검토하는 LLM은 오류를 생성한 것과 동일한 사각지대를 공유합니다. 연구에 따르면 모델은 환각을 일으킬 때 확신에 찬 언어를 사용할 확률이 34% 더 높습니다.
AgentDesk는 적대적 프롬프팅을 사용하는 별도의 검토자 호출을 사용하며, 이는 자기 검토와 근본적으로 다릅니다.
기능 | AgentDesk MCP | 수동 프롬프트 | Braintrust | DeepEval |
단일 도구 설정 | 예 | 아니요 | 아니요 | 아니요 |
적대적 검토 | 예 | DIY | 아니요 | 아니요 |
이중 검토자 | 예 | DIY | 아니요 | 아니요 |
게임화 방지 검증 | 예 | 아니요 | 아니요 | 아니요 |
SDK 불필요 | 예 | 예 | 아니요 | 아니요 |
MCP 네이티브 | 예 | 아니요 | 아니요 | 아니요 |
프롬프트 인젝션: 모든 LLM-as-judge 시스템과 마찬가지로, 적대적 입력이 검토자의 판정을 조작하려고 시도할 수 있습니다. 게임화 방지 검증 계층이 피상적인 조작을 완화하지만, 의도적인 적대적 입력은 여전히 과제로 남아 있습니다. 고위험 사용 사례의 경우 결정론적 검증과 결합하십시오.
BYOK 비용: 각 review_output 호출은 1회의 LLM API 호출을 수행하며, review_dual은 3회를 수행합니다. 이를 파이프라인 비용에 고려하십시오.
HTTP 통합을 선호하는 팀을 위해 추가 기능(에이전트 마켓플레이스, 컨텍스트 학습, 워크플로우)이 포함된 호스팅된 REST API를 agentdesk.usedevtools.com에서 이용할 수 있습니다.
git clone https://github.com/Rih0z/agentdesk-mcp.git
cd agentdesk-mcp
npm install
npm test # 35 tests
npm run buildMIT
제작: EZARK Consulting | 웹 버전
Execute a service on the AgentDesk marketplace. Requires an AgentDesk API key for authentication. Pass service-specific input parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| service_id | Yes | Service ID to execute (e.g., "review", "web_scrape", "realtime_jp", "pdf_generate", "summarize", "classify") | |
| input | Yes | Service-specific input parameters | |
| api_key | No | BYOK: Your Anthropic API key (for AI-powered services like review) |
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 only an authentication requirement (API key) but does not describe side effects (e.g., whether executing a service modifies state), idempotency, rate limits, or error conditions. The description is insufficient for an agent to understand what happens when the tool is invoked.
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 very concise at two sentences with no wasted words. However, it could be more informative within the same length by clarifying the service execution context or referencing the sibling tools. The front-loading is reasonable but the brevity sacrifices completeness.
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 lack of annotations and output schema, the description is insufficiently complete. It does not explain return values, error handling, or how to properly use the api_key parameter. For a tool with nested objects and no output schema, more context is needed to guide the agent effectively.
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 coverage is 100% as all parameters have descriptions. The description adds minimal value: it notes 'service-specific input parameters' but does not elaborate on how to structure the 'input' object for different service IDs. The api_key parameter is described in the schema as 'BYOK: Your Anthropic API key', while the description mentions an 'AgentDesk API key', causing slight inconsistency. Overall, the description does little beyond what the schema already provides.
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 ('Execute a service') and the resource ('AgentDesk marketplace'), providing a specific verb+resource pair. However, it does not distinguish this tool from its siblings (list_services, review_dual, review_output), which could lead to confusion about when to use this generic service execution tool versus those specialized tools.
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 mentions requiring an API key and passing service-specific input, but provides no guidance on when to use this tool versus alternatives like list_services or review_dual. There is no mention of prerequisites (e.g., selecting a service from list_services first) or when not to use this tool. The phrase 'service-specific input parameters' lacks detail on how to determine which parameters are appropriate for a given service_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available services on the AgentDesk marketplace. Returns service catalog with pricing, quality scores, and capabilities. Filter by category, minimum quality score, maximum price, or capability.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category: quality_assurance, web_scraping, realtime_data, document_generation, text_processing | |
| min_score | No | Minimum quality score (0-100) | |
| max_price | No | Maximum price per call in USD | |
| capability | No | Filter by capability keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors; it mentions returning service details but omits pagination, rate limits, or any restrictions. It is adequate but not thorough.
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 two sentences with no wasted words: first sentence states purpose, second adds return content and filters. Extremely concise.
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 simple listing tool with no output schema and no annotations, the description covers the basics but lacks details on pagination, error handling, or output structure, which might be 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?
Input schema has 100% description coverage, and the description merely lists the filter names without adding meaning beyond what the schema already provides, so it meets the baseline.
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 verb 'List' and resource 'available services on the AgentDesk marketplace', and distinguishes from siblings by focusing on browsing the catalog, while sibling tools execute or review services.
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 for browsing services with filters, but does not explicitly state when to use this tool versus alternatives like execute_service or review tools, nor provides exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dual adversarial review: two independent reviewers assess the output from different angles, then a merge agent combines their findings. Stricter than single review — if either reviewer finds a critical issue, the merged verdict is FAIL. Use for high-stakes outputs where quality is critical.
| Name | Required | Description | Default |
|---|---|---|---|
| output | Yes | The AI-generated output to review (max 100K chars) | |
| criteria | No | Custom review criteria | |
| review_type | No | Review category label | |
| model | No | Reviewer model ID (default: claude-sonnet-4-6) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It explains the dual review process and the merge verdict logic, but omits details like side effects, authentication needs, or output structure, leaving gaps for an agent.
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 two sentences: the first explains the process, the second provides usage guidance and the verdict rule. No extraneous words, highly efficient.
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 4 parameters, no output schema, and no annotations, the description adequately explains the core functionality but does not cover output format, error handling, or prerequisites, leaving room for improvement.
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?
With 100% schema description coverage, the schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, so it does not improve understanding of parameter usage.
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 explicitly states the tool performs a dual adversarial review with two independent reviewers and a merge agent. It clearly distinguishes itself from the sibling tool 'review_output' by being stricter and specifying the verdict rule.
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 advises using this tool for high-stakes outputs and contrasts it with single review, but does not explicitly state when not to use it or list alternatives beyond the implied single review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adversarial quality review of any AI-generated output. An independent reviewer assumes the author made mistakes and actively looks for problems. Returns structured verdict (PASS/FAIL/CONDITIONAL_PASS), score (0-100), categorized issues with severity, and evidence-based checklist. Works for any output type: code, content, summaries, translations, data extraction, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| output | Yes | The AI-generated output to review (max 100K chars) | |
| criteria | No | Custom review criteria — what specifically to check for | |
| review_type | No | Review category label (e.g., "code", "content", "factual", "translation") | |
| model | No | Reviewer model ID (default: claude-sonnet-4-6) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It describes the output structure (verdict, score, issues) but does not disclose any potential side effects, destructive actions, authentication needs, or rate limits. The 'adversarial' nature is mentioned but not elaborated.
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 concise at two sentences, front-loading the core purpose and then detailing the output. Every sentence adds value; no redundant or verbose phrasing.
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 no output schema, the description effectively explains the return values (verdict, score, issues, checklist). It covers the tool's broad applicability and key inputs. Minor omissions: it does not clarify that 'criteria' is optional or describe defaults for 'review_type' and 'model'.
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 coverage is 100%—all four parameters have descriptions in the schema. The description does not add additional meaning beyond the schema; it only summarizes the output format. Baseline score of 3 is appropriate.
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 it performs an adversarial quality review of AI-generated output, using specific verbs ('review') and a resource type ('output'). It does not differentiate from the sibling tool 'review_dual', suggesting both may perform reviews, so it misses the top score for sibling distinction.
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 for quality checking of any AI output, but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'review_dual') or when not to use it. It lacks clear context for exclusion or alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.0execute_servicelist_servicesreview_dualreview_outputScored across 4 tools
The four tools are clearly divided into two distinct categories: marketplace services (execute_service, list_services) and output review (review_dual, review_output). Even within the review category, the two tools have well-differentiated purposes (single vs. dual adversarial review), so there is no ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case: execute_service, list_services, review_dual, review_output. The naming is predictable and easy to understand.
With 4 tools, the server covers two distinct functions. While each function could benefit from more tools (e.g., more marketplace operations or review management), the current count is reasonable for a focused server and does not feel excessive or insufficient.
The marketplace side only offers list and execute, lacking create, update, or delete operations for services. The review side provides two types of reviews but no ability to list or manage past reviews. These gaps limit the server's coverage for its implied domain.
Adversarial behavioural-bias engine — audits your decisions for cognitive biases via your own AI.
Expert review for AI agents. On-chain proof of human review.
Agentic code review, no signup to try: reality gates + frontier-model review, with veto.
Devil's-advocate QC API for AIs: post a decision, get strongest counter-argument. 0.1 USDT/call
