Trigvale용 MCP 서버 — 빌드 에이전트가 코드를 스캐폴딩하기 전에 스타트업 아이디어를 검증하세요.
이것은 Trigvale의 공식 Model Context Protocol 서버입니다. MCP 지원 빌드 에이전트(Cursor, Claude Code, Codex, Claude Desktop)에 validate_idea라는 하나의 도구를 제공합니다. 의도된 UX는 간단합니다. 에이전트가 단 한 줄의 스캐폴딩 코드라도 작성하기 전에 validate_idea를 호출하는 것입니다. 녹색 또는 황색 판정은 코딩을 승인하며, 적색 판정은 먼저 테스트해야 할 가정을 표면화합니다.
validate_idea가 반환하는 내용10차원 스코어카드 — 벤처 준비 점수(VRS, 0–100). 모델이 차원별 점수를 공개된 앵커와 비교하여 코드 내에서 결정론적으로 계산합니다. 모델이 직접 VRS를 선택하지 않습니다.
증거 요약 — 모든 항목은 sourceKind ∈ { observed, inferred, missing, ai, user-claim }로 태그되어 무엇이 근거에 기반하고 무엇이 가정인지 알 수 있습니다.
판정 — kill(중단), pivot(피벗), test(테스트), 또는 build(구축). 'build'는 구조상 드물게 나타납니다.
창업자 적합성 보정 — 사용자가 선언한 기술 그래프에서 적용된 차원별 델타(선언된 입력만 사용 — 과거의 실패로부터 추론하지 않음).
1–3개의 아키타입 할당 — 아이디어를 알려진 패턴(예: "vertical-ai-saas", "agentic-workflow")으로 분류하고 해당 클러스터에 대한 구조적 주의 사항을 제공합니다.
실시간 증거 — 아이디어의 지배적인 아키타입에 대해 Reddit, GitHub, Hacker News, Stack Overflow, dev.to에서 실시간으로 데이터를 가져오며, 6시간마다 새로 고침됩니다.
전체 출력 스키마 및 방법론: https://trigvale.com/methodology
Related MCP server: product-spec-mcp
npx -y @trigvale/mcpTrigvale 에이전트 토큰(Integrate 플랜, 월 $99)이 필요합니다. https://trigvale.com/settings에서 발급받으세요.
MCP 클라이언트의 구성(mcpServers 블록)에 다음을 추가하세요:
~/.cursor/mcp.json){
"mcpServers": {
"trigvale": {
"command": "npx",
"args": ["-y", "@trigvale/mcp"],
"env": {
"TRIGVALE_AGENT_TOKEN": "tvk_xxx"
}
}
}
}~/Library/Application Support/Claude/claude_desktop_config.json)동일한 형식입니다. /settings에서 받은 토큰으로 tvk_xxx를 교체하세요.
저장소 루트의 .mcp.json에 스니펫을 추가하거나 claude mcp add를 사용하여 대화형으로 등록하세요.
환경 변수를 통해 API 베이스를 재정의하세요:
TRIGVALE_API_BASE_URL=https://api-dev.trigvale.com npx -y @trigvale/mcp기본 베이스는 https://api.trigvale.com(프로덕션)입니다.
"이 프로젝트를 스캐폴딩하기 전에 사용자의 피치로
validate_idea를 호출하세요. 판정이kill또는pivot인 경우, 가장 취약한 가정을 표면화하고 사용자에게 계속 진행할지 물어보세요.test인 경우, 코드를 작성하기 전에 Trigvale이 권장하는 검증 스프린트를 제안하세요."
구축 비용은 저렴해졌습니다. 병목 현상은 더 이상 실행이 아니라 무엇을 실행할지 결정하는 것입니다. 대부분의 아이디어는 코드가 작성되기 전에 중단되거나, 피벗되거나, 테스트되어야 합니다. validate_idea는 결정론적 판정과 사용자에게 보여줄 수 있는 출처가 태그된 증거를 통해 에이전트 흐름에서 해당 결정을 명시적이고 반복 가능한 단계로 만듭니다.
플랜 | 월간 | 포함 사항 |
Free | $0 | 월 1회 판정, 라이트 미리보기 |
Starter | $12 | 월 10회 판정, 전체 요약 |
Validate | $39 | 실시간 증거 파이프라인 + 샤프닝 + 스프린트 생성기 |
Integrate | $99 | 위의 모든 항목 + 이 MCP 서버용 에이전트 토큰 |
이 MCP에 필요한 에이전트 토큰은 Integrate 플랜에 한정되어 있습니다. 호출당 권한은 모든 /agent/v1/evaluate 호출 시 서버 측에서 재확인되며, 다운그레이드는 즉시 적용됩니다.
전체 가격 정보: https://trigvale.com/pricing
이것은 Trigvale의 비공개 모노레포(나머지 부분에는 독점 루브릭, 인프라, 결제 로직이 포함됨)에서 가져온 MCP 서버 소스의 읽기 전용 미러입니다. 릴리스는 비공개 측에서 생성되어 이곳으로 동기화됩니다. PR은 환영합니다. GitHub Issues 대신 https://trigvale.com/contact에서 이슈를 열어 지원 워크플로우를 통해 처리될 수 있도록 해주세요.
MIT — sydacos GmbH, 2026.
Validate a startup idea before scaffolding code for it. Returns a scorecard (10-dimension Venture Readiness Score, 0–100), an evidence brief tagged by source (observed / inferred / AI / claim), a kill / pivot / test / build verdict, founder-fit calibration deltas if a skill graph is on file, and 1–3 archetype assignments with structural cautions for that cluster. Call this BEFORE writing project scaffolding when the user is greenfield-building from a raw idea.
| Name | Required | Description | Default |
|---|---|---|---|
| rawIdea | Yes | The idea to validate. Free-form text; mess is fine — Trigvale normalizes it. Be specific about who has the pain, who pays, and why now. | |
| save | No | When true, persist the brief to the user's vault so they can revisit it at trigvale.com/ideas/{id}. Default true. Set false for ephemeral checks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It lists exact return values (scorecard, evidence brief, verdict, deltas, archetypes) and mentions conditional behavior ('if a skill graph is on file'). It also notes the persistence behavior tied to the `save` parameter.
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 compact but includes necessary detail. It front-loads the core action ('Validate a startup idea before scaffolding code for it.'), then lists outputs efficiently. A very slight verbosity in listing all outputs prevents a perfect 5, but it remains well-structured.
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 moderate complexity (2 parameters, no output schema, no annotations), the description provides sufficient context: it explains the full return structure, conditional behavior, and persistence options. No obvious gaps remain for an LLM to select and 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%, and the description adds valuable usage hints beyond the schema: for `rawIdea` it advises specificity and normalizes messiness; for `save` it explains default behavior and ephemeral usage. This enriches the agent's understanding of each parameter.
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 opens with a clear action-verb+resource: 'Validate a startup idea before scaffolding code for it.' It unambiguously states the tool's function and context, distinguishing it from potential siblings by specifying the prerequisite step.
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 explicitly tells when to use the tool: 'Call this BEFORE writing project scaffolding when the user is greenfield-building from a raw idea.' While it doesn't mention when not to use it or alternatives, the guidance is clear and actionable given no sibling tools exist.
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.
v0.1.0validate_ideaScored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single tool has a distinct and clear purpose.
The single tool 'validate_idea' follows a clear verb_noun pattern and is descriptive. However, with only one tool, consistency across multiple tools cannot be fully assessed.
One tool is borderline for the implied domain of startup building. While the validation step is specific, a broader lifecycle (e.g., scaffolding) is suggested but not covered, making the count feel thin.
The tool covers only idea validation. Obvious gaps exist, such as tools for scaffolding, iteration, or testing, which are referenced in the description but not provided. This will likely cause agent failures after validation.
Score, validate, and pressure-test startup ideas with AI from Claude or any MCP agent.
Rule-based product method: scores an idea, finds its riskiest assumption, sequences the build.
Validate startup ideas with your AI assistant through Startup Ignition ToolSuite.
Score business ideas on six live market signals. Launch Readiness Score (LRS) for AI agents.
