Open Strategy Partners 의 검증된 방법론을 기반으로 한 기술 마케팅 콘텐츠 제작, 최적화 및 제품 포지셔닝을 위한 포괄적인 도구 모음입니다.
이 소프트웨어는 MCP(Model Context Protocol) 를 기반으로 하며 MCP를 지원하는 모든 LLM 클라이언트에서 사용할 수 있습니다.
2025년 2월 초 현재 MCP를 지원하는 LLM 클라이언트는 다음과 같습니다.
Claude 데스크톱 앱은 기술에 익숙하지 않은 사람들이 사용하기 가장 쉬운 앱입니다(MCP를 만든 사람이 만든 앱입니다).
커서 IDE 는 우리 개발자 친구들에게 매우 인기가 많습니다.
LibreChat 은 뛰어난 오픈 소스 AI/LLM 인터페이스 앱입니다.
Agentic AI가 마케팅에 어떤 이점을 제공하는지 에 대한 비전 논문을 읽어보세요.
제품의 가치와 위치를 효과적으로 전달하는 구조화된 OSP 제품 가치 맵을 생성하세요.
태그라인 생성 및 개선
시장, 기술, UX 및 비즈니스 차원에 걸친 입장 표명
역할, 과제, 필요 사항을 고려한 페르소나 개발
가치 사례 문서
기능 분류 및 구성
기능, 영역 및 범주에 대한 계층 구조
완전성과 일관성을 위한 검증 시스템
웹 콘텐츠에 최적화된 메타데이터를 만듭니다.
적절한 키워드 배치를 통한 기사 제목(H1)
검색에 최적화된 메타 타이틀(50~60자)
명확한 가치 제안이 포함된 메타 설명(155~160자)
SEO 친화적인 URL 슬러그
검색 의도 분석
모바일 디스플레이 최적화
클릭률 향상 제안
포괄적인 콘텐츠 검토를 위해 OSP의 의미 편집 코드를 적용하세요.
범위 및 서사 구조 분석
흐름과 가독성 향상
스타일 및 구문 최적화
단어 선택 및 문법 검증
기술적 정확도 검증
포괄적인 언어 지도
이전/이후 사례를 통한 건설적인 피드백 생성
고품질 기술 콘텐츠를 만드는 체계적인 접근 방식:
서사 구조 개발
흐름 최적화
스타일 가이드라인
기술적 정확도 검증
콘텐츠 유형별 지침(튜토리얼, 참조 문서, API 문서)
접근성 고려 사항
국제화 모범 사례
품질 보증 체크리스트
검색 엔진과 사용자 경험을 위해 웹 콘텐츠를 최적화하는 포괄적인 시스템:
메타 콘텐츠 최적화(제목, 문자 제한이 있는 설명 및 키워드 배치)
콘텐츠 심도 강화(하위 주제, 데이터 통합, 다중 형식 최적화)
검색 의도 정렬(5가지 유형: 정보, 탐색, 거래, 상업, 지역)
기술적 SEO 구현(키워드 조사, 통합 프로토콜, 내부 링크 규칙)
구조화된 데이터 배포(FAQ, 방법, 제품 스키마)
콘텐츠 홍보 전략(소셜 미디어, 광고 접근 방식)
품질 검증 프로토콜(건설적 피드백, 차이 기반 수정 시스템)
성과 측정 방법(CTR, 이탈률, 페이지 측정 시간)
Related MCP server: PrivateGPT MCP Server
이 모든 예에서, 귀하는 개선하고자 하는 텍스트나 귀하가 마케팅하고 있는 제품을 설명하는 기술 문서를 제공할 것이라고 가정합니다.
지엑스피1
Prompt: "Use the OSP meta tool to generate metadata for an article about [topic]. Primary keyword: [keyword], audience: [target audience], content type: [type]"
Example:
"Use the OSP meta tool to generate metadata for an article about containerization best practices. Primary keyword: 'Docker containers', audience: system administrators, content type: technical guide"Prompt: "Review this technical content using OSP editing codes: [paste content]"
Example:
"Review this technical content using OSP editing codes:
Kubernetes helps you manage containers. It's really good at what it does. You can use it to deploy your apps and make them run better."Prompt: "Apply the OSP writing guide to create a [document type] about [topic] for [audience]"
Example:
"Apply the OSP writing guide to create a tutorial about setting up a CI/CD pipeline for junior developers"Claude Desktop(또는 다른 MCP 지원 AI 도구) 설치
데스크톱용 Claude 다운로드
현재 설치 지침을 따르세요: Claude Desktop 설치
Python 3.10 이상을 설치하세요:
python.org 에서 최신 Python 설치 프로그램을 다운로드하세요
설치 프로그램을 실행하고 "PATH에 Python 추가"를 체크합니다.
명령 프롬프트를 열고 python --version 으로 설치를 확인하세요.
uv 설치:
관리자 권한으로 명령 프롬프트를 엽니다
pip install --user uv 실행합니다.
uv --version 으로 설치를 확인하세요
Claude Desktop(또는 다른 MCP 지원 AI 도구) 설치
데스크톱용 Claude 다운로드
현재 설치 지침을 따르세요: Claude Desktop 설치
Python 3.10 이상을 설치하세요:
Homebrew 사용: brew install python
python3 --version 으로 설치를 확인하세요
uv 설치:
Homebrew 사용: brew install uv
또는: pip3 install --user uv
uv --version 으로 설치를 확인하세요
claude_desktop_config.json 에 다음을 추가하세요.
{
"mcpServers": {
"osp_marketing_tools": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/open-strategy-partners/osp_marketing_tools@main",
"osp_marketing_tools"
]
}
}
}이 소프트웨어 패키지는 Open Strategy Partners 에서 개발한 콘텐츠 제작 및 최적화 방법론을 구현합니다. LLM 지원 마케팅 도구와 전문적인 콘텐츠 제작 프레임워크를 기반으로 합니다.
더 많은 정보와 원본 자료를 보려면 다음 사이트를 방문하세요.
본 소프트웨어는 크리에이티브 커먼즈 코퍼레이션("크리에이티브 커먼즈")의 저작자표시-동일조건변경허락 4.0 국제 라이선스에 따라 라이선스가 부여되었습니다.
즉, 다음을 자유롭게 수행할 수 있습니다.
공유: 자료를 어떤 매체나 형식으로든 복사하고 재배포할 수 있습니다.
적응: 상업적인 목적을 포함하여 어떤 목적이든 자료를 리믹스, 변형하고 구축합니다.
다음 조건에 따라:
귀속: Open Strategy Partners에 적절한 크레딧을 제공하고 라이선스에 대한 링크를 제공하며 변경 사항이 있는 경우 표시해야 합니다.
ShareAlike: 자료를 리믹스, 변형 또는 구축하는 경우 기여물을 원본과 동일한 라이선스에 따라 배포해야 합니다.
전체 라이선스 텍스트를 보려면 Creative Commons Attribution-ShareAlike 4.0 International License를 방문하세요.
이 도구들을 개선하기 위한 여러분의 기여를 환영합니다. 저희 저장소를 통해 이슈와 풀 리퀘스트를 제출해 주세요.
질문과 지원:
문서를 확인하세요
저장소에 문제를 제출하세요
전문 컨설팅을 원하시면 Open Strategy Partners에 문의하세요.
Get the Open Strategy Partners (OSP) editing codes documentation and usage protocol for editing texts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 implies a read-only operation ('Get') and specifies the content type ('documentation and usage protocol'), but doesn't detail aspects like authentication needs, rate limits, error handling, or response format. For a tool with zero annotation coverage, this offers basic context but lacks comprehensive 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, efficient sentence that directly states the tool's purpose without any redundant information. It is front-loaded with the key action and resource, making it easy to parse and understand quickly. Every word contributes to clarifying the tool's intent.
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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on output format, error cases, or integration with sibling tools. Without annotations or output schema, more context on behavioral aspects would improve completeness, but it meets the basic requirement for a simple retrieval tool.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but with no parameters, this is acceptable. It provides a baseline understanding of the tool's function without unnecessary complexity.
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 tool's purpose: to retrieve documentation and usage protocol for OSP editing codes. It specifies the resource ('OSP editing codes documentation and usage protocol') and the action ('Get'), though it doesn't explicitly differentiate from sibling tools like 'get_writing_guide' or 'get_meta_guide', which might also provide documentation. This makes it clear but not fully sibling-distinctive.
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. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'get_writing_guide' or 'get_meta_guide', leaving the agent without context for tool selection. This lack of explicit usage instructions results in minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Open Strategy Partners (OSP) Web Content Meta Information Generation System (titles, meta-titles, slugs).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. The description only states what the tool retrieves but doesn't disclose behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, or what the output format might be. For a 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 directly states the tool's purpose without unnecessary words. It's appropriately sized for a no-parameter tool, though it could be slightly more structured by front-loading key details like the verb 'retrieve' more explicitly.
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 incomplete. It doesn't explain what the tool returns (e.g., a list, a single object, or structured data), any behavioral constraints, or how it differs from sibling tools. For a tool with no structured metadata, the description should provide more context to aid the agent.
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 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are no parameters. This aligns with the baseline expectation for tools without parameters, as there's nothing to compensate for.
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 states the tool retrieves 'Web Content Meta Information Generation System' data including titles, meta-titles, and slugs, which is a clear purpose. However, it doesn't specify what 'get' means operationally (e.g., fetch all, fetch by ID, search) or differentiate from sibling tools like 'get_on_page_seo_guide' that might overlap in scope. The description is somewhat vague about the exact nature of the retrieval.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools, prerequisites, or specific contexts for usage. It's left to the agent to infer based on the tool name and description alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Open Strategy Partners (OSP) On-Page SEO Optimization Guide.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does but doesn't describe how it behaves—e.g., whether it returns a static document, requires authentication, has rate limits, or provides real-time data. This leaves critical behavioral traits unspecified.
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 directly states the tool's purpose with no unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It tells the agent what resource is retrieved but lacks context about the guide's format, update frequency, or how it differs from sibling tools. For a retrieval tool with no behavioral annotations, more detail would be helpful.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids mentioning any. A baseline of 4 is applied for zero-parameter tools.
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 ('Get') and resource ('Open Strategy Partners (OSP) On-Page SEO Optimization Guide'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this guide from sibling tools like 'get_meta_guide' or 'get_writing_guide', which might also be SEO-related guides.
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 'get_meta_guide' or 'get_writing_guide'. It doesn't mention prerequisites, context, or any exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Open Strategy Partners (OSP) Product Communications Value Map Generation System for Product Positioning (value cases, feature extraction, taglines).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool 'gets' a system, implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, response format, or potential side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 key action ('Get') and resource. It avoids unnecessary words, though it could be slightly more structured by separating the system name from its purpose for clarity. Overall, it's appropriately sized with minimal waste.
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 complexity (simple retrieval with no parameters), no annotations, and no output schema, the description is adequate but incomplete. It specifies what is retrieved but lacks details on the return format, usage context, or behavioral traits. For a tool with minimal structured data, it meets a basic threshold but leaves 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?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it does specify what is being retrieved (the OSP system), which aligns with the lack of inputs. A baseline of 4 is appropriate for zero-parameter tools.
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 tool's purpose: retrieving a specific system (OSP Product Communications Value Map Generation System) for product positioning tasks like value cases, feature extraction, and taglines. It uses a specific verb ('Get') and identifies the resource, though it doesn't explicitly differentiate from sibling tools like 'get_meta_guide' or 'get_writing_guide' beyond naming the system.
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. It mentions the system's purpose (product positioning) but doesn't specify contexts, prerequisites, or exclusions, nor does it reference sibling tools for comparison. Usage is implied by the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Open Strategy Partners (OSP) writing guide and usage protocol for editing texts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool retrieves a guide and protocol, implying a read-only operation, but doesn't clarify aspects like whether authentication is required, if there are rate limits, what format the output is in, or if the data is static or dynamic. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 directly states the tool's purpose without unnecessary words. It's front-loaded with the key action ('Get') and resource, making it easy to parse. Every part of the sentence contributes to understanding the tool's function, with zero waste.
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 complexity is low (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on output format, behavioral traits, or differentiation from siblings. Without annotations or an output schema, the description should ideally provide more context about what to expect from the tool, but it meets the basic requirement for a simple retrieval tool.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline score of 4 is given since no parameters exist, and the description doesn't introduce confusion about inputs.
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 ('Get') and resource ('Open Strategy Partners writing guide and usage protocol for editing texts'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its siblings like 'get_editing_codes' or 'get_meta_guide', which might also provide guidance-related content. The purpose is clear but lacks sibling differentiation.
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. It doesn't mention what makes this writing guide unique compared to other guides available (e.g., 'get_meta_guide' or 'get_on_page_seo_guide'), nor does it specify any prerequisites or contexts where this tool is preferred. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the server is running and can access its resources
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 checking server status and resource access but does not detail what 'resources' entail, expected response formats, error handling, or any side effects (e.g., logging, performance impact). This leaves significant gaps for a tool with zero annotation coverage.
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, clear sentence that efficiently conveys the tool's purpose without redundancy. It is front-loaded and wastes no words, making it highly concise and 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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, output, or integration context. For a health check tool, more information on expected results or usage scenarios would improve completeness.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, aligning with the schema. A baseline of 4 is applied since no parameters exist, and the description does not add unnecessary information.
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 tool's purpose: 'Check if the server is running and can access its resources.' It specifies the verb ('Check') and the target ('server'), making the action explicit. However, it does not differentiate from siblings (e.g., other diagnostic or status tools), which prevents a score of 5.
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. It lacks context about prerequisites, timing (e.g., after errors or periodically), or comparisons with sibling tools, leaving the agent without usage direction.
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.
get_editing_codesget_meta_guideget_on_page_seo_guideget_value_map_positioning_guideget_writing_guidehealth_checkScored across 6 tools
Every tool has a clearly distinct purpose targeting specific documentation or guides (editing codes, meta guide, SEO guide, value map, writing guide, health check). There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.
All tools follow a consistent verb_noun pattern with 'get_' prefix for documentation retrieval tools and a clear descriptive noun (e.g., get_editing_codes, get_meta_guide). The health_check tool also fits a standard naming convention, maintaining uniformity throughout the set.
With 6 tools, the count is reasonable and well-scoped for a marketing documentation server, covering key areas like editing, SEO, and positioning. It's slightly lean but appropriate, as each tool serves a distinct purpose without redundancy.
The tool set provides comprehensive retrieval for various marketing guides, but it lacks CRUD operations (e.g., create or update guides) and other lifecycle actions. This is a notable gap, as agents can only get information without modifying or interacting beyond basic health checks.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Any REST/SOAP/GraphQL/OData/SQL API as MCP tools for Claude & ChatGPT. 325 connectors: SAP, ERP.
MCP-Native LLM Orchestration Agent
