基于开放战略合作伙伴经过验证的方法，用于技术营销内容创建、优化和产品定位的综合工具套件。
该软件基于模型上下文协议 (MCP) ，可供任何支持 MCP 的 LLM 客户端使用。
截至 2025 年 2 月初，支持 MCP 的 LLM 客户端包括：
对于我们当中技术水平较低的人来说，Claude 桌面应用程序是最容易使用的（它是由 MCP 的发明者制作的）。
Cursor IDE在我们的开发人员朋友中非常受欢迎。
LibreChat是一款优秀的开源 AI/LLM 界面应用程序。
阅读我们的愿景文件，了解Agentic AI 如何使营销受益。
生成结构化的OSP 产品价值图，有效传达您的产品价值和定位：
标语的创作和完善
涵盖市场、技术、用户体验和业务维度的立场声明
角色、挑战和需求的角色发展
价值案例文档
特征分类和组织
特征、区域和类别的层次结构
完整性和一致性验证系统
为 Web 内容创建优化的元数据：
文章标题（H1）带有适当的关键词位置
针对搜索进行优化的元标题（50-60 个字符）
具有明确价值主张的元描述（155-160 个字符）
SEO友好的URL段
搜索意图分析
移动显示优化
点击率提升建议
应用OSP的语义编辑代码进行全面的内容审查：
范围和叙事结构分析
流程和可读性增强
风格和措辞优化
词汇选择和语法验证
技术准确性验证
包容性语言指导
通过前后示例生成建设性反馈
创建高质量技术内容的系统方法：
叙事结构发展
流程优化
风格指南
技术准确性验证
内容类型特定指南（教程、参考文档、API 文档）
无障碍设施注意事项
国际化最佳实践
质量保证清单
用于优化搜索引擎和用户体验的网络内容的综合系统：
元内容优化（标题、字符限制的描述和关键字放置）
内容深度提升（子主题、数据整合、多格式优化）
搜索意图一致性（5 种类型：信息、导航、交易、商业、本地）
技术 SEO 实施（关键词研究、集成协议、内部链接规则）
结构化数据部署（常见问题解答、操作方法、产品架构）
内容推广策略（社交媒体、广告方式）
质量验证协议（建设性反馈、基于差异的修订系统）
绩效衡量方法（点击率、跳出率、页面停留时间指标）
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 Desktop
安装 Python 3.10 或更高版本：
从python.org下载最新的 Python 安装程序
运行安装程序，选中“将 Python 添加到 PATH”
打开命令提示符并使用python --version验证安装
安装 uv：
以管理员身份打开命令提示符
运行pip install --user uv
使用uv --version验证安装
安装 Claude Desktop（或其他支持 MCP 的 AI 工具）
按照当前安装说明：安装 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 适当的认可，提供许可证链接，并注明是否进行了更改
相同方式共享：如果您对素材进行重新混合、转换或创作，则必须按照与原始素材相同的许可分发您的贡献
完整许可文本请访问：知识共享署名-相同方式共享 4.0 国际许可
我们欢迎大家为改进这些工具做出贡献。请通过我们的代码库提交问题和拉取请求。
如有疑问或需要支持，请联系：
查看我们的文档
在我们的存储库中提交问题
联系 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
