The software is licensed under Creative Commons Attribution-ShareAlike 4.0 International license, allowing users to share, adapt, and build upon the material while providing appropriate attribution to Open Strategy Partners.
Mentioned in usage examples for generating metadata related to containerization best practices and Docker containers specifically.
Used to host and distribute the MCP server code, allowing users to install the package directly from GitHub repository.
Mentioned in usage examples for content editing and as a topic for technical content that can be enhanced using the OSP editing tools.
Provides specific installation instructions for macOS users, including using Homebrew to install required dependencies.
Required as a dependency for running the MCP server, with specific version requirements (3.10 or higher).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OSP Marketing Tools MCP Server generate an OSP value map for our new API gateway focusing on enterprise developers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive suite of tools for technical marketing content creation, optimization, and product positioning based on Open Strategy Partners' proven methodologies.
This software is based on the Model Context Protocol (MCP) and is can be used by any LLM client that supports the MCP.
As of early February 2025, the LLM clients that support MCP include:
Claude desktop app is the easiest to use for the less technical among us (and it is made by the inventors of the MCP).
Cursor IDE is very popular with our developer friends.
LibreChat is an excellent open source AI/LLM interface app.
Read our vision paper on how Agentic AI will benefit marketing.
Generate structured OSP product value maps that effectively communicate your product's worth and positioning:
Tagline creation and refinement
Position statements across market, technical, UX, and business dimensions
Persona development with roles, challenges, and needs
Value case documentation
Feature categorization and organization
Hierarchical structure for features, areas, and categories
Validation system for completeness and consistency
Create optimized metadata for web content:
Article titles (H1) with proper keyword placement
Meta titles optimized for search (50-60 characters)
Meta descriptions with clear value propositions (155-160 characters)
SEO-friendly URL slugs
Search intent analysis
Mobile display optimization
Click-through rate enhancement suggestions
Apply OSP's semantic editing codes for comprehensive content review:
Scope and narrative structure analysis
Flow and readability enhancement
Style and phrasing optimization
Word choice and grammar verification
Technical accuracy validation
Inclusive language guidance
Constructive feedback generation with before/after examples
Systematic approach to creating high-quality technical content:
Narrative structure development
Flow optimization
Style guidelines
Technical accuracy verification
Content type-specific guidance (tutorials, reference docs, API documentation)
Accessibility considerations
Internationalization best practices
Quality assurance checklists
Comprehensive system for optimizing web content for search engines and user experience:
Meta content optimization (titles, descriptions with character limits and keyword placement)
Content depth enhancement (subtopics, data integration, multi-format optimization)
Search intent alignment (5 types: informational, navigational, transactional, commercial, local)
Technical SEO implementation (keyword research, integration protocols, internal linking rules)
Structured data deployment (FAQ, How-To, Product schemas)
Content promotion strategies (social media, advertising approaches)
Quality validation protocol (constructive feedback, diff-based revision system)
Performance measurement methods (CTR, bounce rate, time on page metrics)
Related MCP server: PrivateGPT MCP Server
In all of these examples, it is assumed that you will provide the texts that you wish to improve, or the technical documentation that describes the product you are marketing.
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"Install Claude Desktop (or another MCP-enabled AI tool)
Download Claude for Desktop
Follow the current installation instructions: Installing Claude Desktop
Install Python 3.10 or higher:
Download the latest Python installer from python.org
Run the installer, checking "Add Python to PATH"
Open Command Prompt and verify installation with python --version
Install uv:
Open Command Prompt as Administrator
Run pip install --user uv
Verify installation with uv --version
Install Claude Desktop (or another MCP-enabled AI tool)
Download Claude for Desktop
Follow the current installation instructions: Installing Claude Desktop
Install Python 3.10 or higher:
Using Homebrew: brew install python
Verify installation with python3 --version
Install uv:
Using Homebrew: brew install uv
Alternatively: pip3 install --user uv
Verify installation with uv --version
Add the following to your 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"
]
}
}
}This software package implements the content creation and optimization methodologies developed by Open Strategy Partners. It is based on their LLM-enabled marketing tools and professional content creation frameworks.
For more information and original resources, visit:
This software is licensed under the Attribution-ShareAlike 4.0 International license from Creative Commons Corporation ("Creative Commons").
This means you are free to:
Share: Copy and redistribute the material in any medium or format
Adapt: Remix, transform, and build upon the material for any purpose, even commercially
Under the following terms:
Attribution: You must give appropriate credit to Open Strategy Partners, provide a link to the license, and indicate if changes were made
ShareAlike: If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original
For the full license text, visit: Creative Commons Attribution-ShareAlike 4.0 International License
We welcome contributions to improve these tools. Please submit issues and pull requests through our repository.
For questions and support:
Check our documentation
Submit an issue in our repository
Contact Open Strategy Partners for professional consulting
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/open-strategy-partners/osp_marketing_tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
