Open Strategy Partnersの実証済みの方法論に基づいた、テクニカル マーケティング コンテンツの作成、最適化、および製品の位置付けのための包括的なツール スイートです。
このソフトウェアはモデル コンテキスト プロトコル (MCP)に基づいており、MCP をサポートする任意の LLM クライアントで使用できます。
2025 年 2 月初旬現在、MCP をサポートする LLM クライアントは次のとおりです。
Claude デスクトップ アプリは、技術に詳しくない人にとって最も使いやすいアプリです (MCP の発明者によって作成されています)。
Cursor IDE は、開発者の友人の間で非常に人気があります。
LibreChatは、優れたオープンソース AI/LLM インターフェイス アプリです。
Agentic AI がマーケティングにどのようなメリットをもたらすかについては、当社のビジョン ペーパーをお読みください。
製品の価値と位置付けを効果的に伝える構造化されたOSP 製品価値マップを生成します。
タグラインの作成と改良
市場、技術、UX、ビジネスの各側面におけるポジションステートメント
役割、課題、ニーズを考慮したペルソナ開発
価値事例ドキュメント
機能の分類と整理
機能、エリア、カテゴリの階層構造
完全性と一貫性のための検証システム
Web コンテンツに最適化されたメタデータを作成します。
適切なキーワードを配置した記事タイトル（H1）
検索に最適化されたメタタイトル（50～60文字）
明確な価値提案を含むメタディスクリプション（155～160文字）
SEOに適したURLスラッグ
検索意図分析
モバイルディスプレイの最適化
クリックスルー率向上の提案
包括的なコンテンツレビューのためにOSP のセマンティック編集コードを適用します。
スコープと物語構造の分析
フローと読みやすさの向上
スタイルとフレーズの最適化
単語の選択と文法の検証
技術的精度の検証
包括的な言語ガイダンス
前後の例を用いた建設的なフィードバックの生成
高品質な技術コンテンツを作成するための体系的なアプローチ:
物語構造の発展
フロー最適化
スタイルガイドライン
技術的正確性の検証
コンテンツタイプ固有のガイダンス（チュートリアル、リファレンスドキュメント、APIドキュメント）
アクセシビリティに関する考慮事項
国際化のベストプラクティス
品質保証チェックリスト
検索エンジンとユーザーエクスペリエンスのためにウェブコンテンツを最適化する包括的なシステム:
メタコンテンツの最適化（タイトル、文字数制限のある説明、キーワードの配置）
コンテンツの深度強化（サブトピック、データ統合、マルチフォーマットの最適化）
検索意図の調整（5 種類：情報、ナビゲーション、トランザクション、コマーシャル、ローカル）
技術的な SEO 実装（キーワード調査、統合プロトコル、内部リンクルール）
構造化データの展開（FAQ、ハウツー、製品スキーマ）
コンテンツプロモーション戦略（ソーシャルメディア、広告アプローチ）
品質検証プロトコル（建設的なフィードバック、差分ベースの改訂システム）
パフォーマンス測定方法（クリック率、直帰率、ページ滞在時間指標）
Related MCP server: PrivateGPT MCP Server
これらすべての例では、改善したいテキスト、またはマーケティングしている製品を説明する技術文書を提供することが前提となっています。
Prompt: "Generate an OSP value map for [Product Name] focusing on [target audience] with the following key features: [list features]"
Example:
"Generate an OSP value map for CloudDeploy, focusing on DevOps engineers with these key features:
- Automated deployment pipeline
- Infrastructure as code support
- Real-time monitoring
- Multi-cloud compatibility
- [the rest of your features or text]"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インストーラーをダウンロードします。
「PythonをPATHに追加する」をチェックしてインストーラを実行します。
コマンドプロンプトを開き、 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対応のマーケティングツールとプロフェッショナルなコンテンツ作成フレームワークに基づいています。
詳細情報と元のリソースについては、次の Web サイトをご覧ください。
このソフトウェアは、Creative Commons Corporation (以下「Creative Commons」) の Attribution-ShareAlike 4.0 International ライセンスに基づいてライセンスされています。
つまり、次のことが自由に行えます:
共有: あらゆる媒体や形式で資料をコピーおよび再配布できます
適応: 商業目的であっても、あらゆる目的で素材をリミックス、変形、構築する
以下の条件に基づきます。
帰属: 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. 299 connectors: SAP, ERP.
MCP-Native LLM Orchestration Agent
