Used in examples for tool generation, such as converting Markdown text to HTML.
Generates production-ready TypeScript tool definitions, implementations, and test suites following the CTP specification with full type safety.
Used in examples for tool generation, such as converting YAML to JSON format.
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., "@CTP MCP Server create a tool that converts CSV files to JSON format"
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.
MCP server for AI-powered CTP tool generation - describe a tool, get production-ready code.
The CTP MCP Server is a Model Context Protocol server that helps developers create ConveniencePro Tool Protocol (CTP) tools quickly and easily. Simply describe what tool you want to build, and the MCP server generates complete, production-ready code including:
Tool definitions following the CTP specification
Implementation code (client-side or server-side)
Complete test suites
TypeScript types and validation
Related MCP server: JIT Tool Synthesis
AI-Powered Generation: Describe your tool in natural language
Complete Scaffolding: Get definition, implementation, and tests
CTP Validation: Ensures generated tools follow the specification
Duplicate Detection: Checks for similar existing tools
Template-Based: Consistent, best-practice code generation
Type-Safe: Full TypeScript support
npm install -g @conveniencepro/ctp-mcp-serverOr use directly with npx:
npx @conveniencepro/ctp-mcp-serverAdd to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"ctp-tools": {
"command": "npx",
"args": ["-y", "@conveniencepro/ctp-mcp-server"]
}
}
}ctp_create_toolGenerate a complete CTP tool from a natural language description.
Parameters:
description (required): Natural language description of what the tool should do
name (optional): Tool name (auto-generated if not provided)
category (optional): Tool category
executionMode (optional): Where the tool runs (client, server, or both)
Example:
Create a tool that converts YAML to JSONctp_validate_toolValidate a tool definition against the CTP specification.
Parameters:
definition (required): The tool definition object to validate
ctp_generate_implementationGenerate implementation code from a tool definition.
Parameters:
definition (required): The tool definition
executionMode (optional): Execution mode (client or server)
ctp_generate_testsGenerate a test suite for a CTP tool.
Parameters:
definition (required): The tool definition
implementation (optional): The tool implementation code
ctp_search_duplicatesSearch for existing tools with similar functionality.
Parameters:
description (required): Description of the tool to search for
category (optional): Category to narrow search
Search for duplicates:
Use ctp_search_duplicates to check if a "markdown to HTML converter" already existsGenerate the tool:
Use ctp_create_tool with description: "Convert Markdown text to HTML"Review generated files:
src/tools/markdown-to-html-definition.ts - Tool definition
src/tools/markdown-to-html.ts - Implementation
src/tools/__tests__/markdown-to-html.test.ts - Tests
Implement the logic: Replace the placeholder implementation with actual logic
Test and deploy:
npm test
npm run build// Tool Definition
export const markdownToHtmlDefinition: ToolDefinition = {
id: 'markdown-to-html',
name: 'Markdown to HTML',
description: 'Convert Markdown text to HTML',
category: 'converters',
// ... full specification
};
// Implementation
export const markdownToHtmlFn: ToolFunction<MarkdownToHtmlResult> = (params) => {
// Your implementation here
};
// Tests
describe('Markdown to HTML', () => {
it('should convert markdown to HTML', () => {
// Generated tests
});
});# Clone the repository
git clone https://github.com/titan-alpha/ctp-mcp-server.git
cd ctp-mcp-server
# Install dependencies
npm install
# Build
npm run build
# Run locally
npm startctp-mcp-server/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── tools/ # MCP tool implementations
│ │ ├── create-tool.ts # Tool scaffolding
│ │ ├── validate-tool.ts # Validation
│ │ ├── generate-*.ts # Code generators
│ │ └── search-*.ts # Duplicate detection
│ ├── templates/ # Handlebars templates
│ │ ├── tool-definition.hbs
│ │ ├── client-implementation.hbs
│ │ └── test-suite.hbs
│ └── utils/ # Utilities
│ ├── template-engine.ts
│ ├── string-utils.ts
│ └── ai-analyzer.ts
└── dist/ # Compiled outputContributions are welcome! Please see the CTP repository for contribution guidelines.
MIT
@conveniencepro/ctp-core - Core types and validation
@conveniencepro/ctp-runtime - Execution runtime
@conveniencepro/ctp-sdk - Embeddable SDK
@conveniencepro/ctp-examples - Example tools
Generate a complete CTP tool from a natural language description. Creates tool definition, implementation, and tests.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Natural language description of what the tool should do | |
| name | No | Tool name (optional - will be auto-generated if not provided) | |
| category | No | Tool category (e.g., "converters", "calculators", "generators") | |
| executionMode | No | Where the tool should execute (default: client) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions what the tool creates, but omits side effects, permissions, or state changes (e.g., whether files are written, if auth is needed). The absence of such detail for a creation tool leaves significant transparency gaps.
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 concise at two sentences, front-loaded with the core purpose, and contains no extraneous information. Every word adds value.
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 complexity (4 params, 1 required, no output schema), the description lacks details about output format, location, or side effects. It does not compensate for the missing output schema or provide enough context for an agent to fully understand the tool's behavior.
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 100% description coverage, with each parameter (description, name, category, executionMode) already well-documented. The description adds minimal extra meaning, so the baseline of 3 applies.
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 generates a complete CTP tool from a natural language description, including definition, implementation, and tests. This distinctively differentiates it from sibling tools like ctp_generate_implementation and ctp_generate_tests, which focus on specific parts.
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 implies the tool is for generating a full tool from scratch, but it does not provide explicit guidance on when to use this versus sibling tools (e.g., when to use ctp_generate_implementation instead). No when-not-to-use or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate implementation code from a tool definition
| Name | Required | Description | Default |
|---|---|---|---|
| definition | Yes | The tool definition | |
| executionMode | No | Execution mode (default: client) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose any behavioral traits such as side effects, required permissions, or output format. The description is too vague to inform safe invocation.
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 extremely concise with a single sentence that clearly states the purpose. No wasted words.
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 no output schema and a nested object parameter, the description lacks essential context. It does not explain what 'implementation code' means, what language or format, or any constraints, making it insufficient for an agent to fully understand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what is in the schema, leading to a baseline score of 3.
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 it generates implementation code from a tool definition, using a specific verb and resource. It distinguishes from sibling tools like ctp_create_tool (create definitions) and ctp_generate_tests (generate tests).
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 ctp_validate_tool or ctp_search_duplicates. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate test suite for a CTP tool
| Name | Required | Description | Default |
|---|---|---|---|
| definition | Yes | The tool definition | |
| implementation | No | The tool implementation code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description is too brief. Does not disclose whether tests are generated from existing files, what schema of test suite is, or side effects (e.g., file creation).
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?
One sentence is concise but not overly terse; however, could include more context without becoming verbose.
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?
Minimal description for a tool with 2 parameters and nested objects. Lacks details on output or process, making it partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and provides descriptions for both parameters. Description adds no further detail beyond schema, so baseline score of 3 applies.
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?
Description clearly states action 'generate test suite' and resource 'CTP tool', distinct from siblings like ctp_create_tool (creates tool) and ctp_generate_implementation (generates implementation).
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 on when to use this tool vs alternatives. Does not mention prerequisites (e.g., tool must be defined) or context (e.g., after implementation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for existing tools with similar functionality
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Description of the tool to search for | |
| category | No | Optional category to narrow search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full responsibility. It implies a read-only search but lacks details on scope (e.g., all tools or project-wide), rate limits, or whether the search is fuzzy or exact. Minimal behavioral context.
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?
Single sentence is concise, but at the expense of informativeness. Could be improved with additional context without sacrificing brevity.
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 no output schema or annotations, the description fails to explain return format, how similarity is determined, or how to interpret results. Incomplete for a search 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?
Schema coverage is 100%, so description adds no value beyond schema. The description's mention of 'similar functionality' aligns with the 'description' parameter but does not enhance parametric understanding.
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?
Description clearly states the action (search) and resource (existing tools with similar functionality), distinguishing it from sibling tools like ctp_create_tool. It is specific but could be more precise about what 'similar functionality' entails.
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 on when to use this tool versus alternatives like ctp_create_tool. Does not mention prerequisites, such as searching before creating a tool, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a tool definition against the CTP specification
| Name | Required | Description | Default |
|---|---|---|---|
| definition | Yes | The tool definition to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states 'validate', implying a read-only operation, but lacks details on side effects, expected outcomes, or error handling. This is insufficient for a validation tool.
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 concise sentence that immediately conveys the tool's purpose. No unnecessary information, and it is front-loaded.
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 should provide more context about the validation process, such as what constitutes a valid definition or the format of results. It is incomplete and leaves the agent without critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'The tool definition to validate'. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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 'validate' and the resource 'a tool definition against the CTP specification'. It effectively distinguishes from sibling tools like ctp_create_tool and ctp_generate_implementation.
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, such as when to validate before creation or after modification. No explicit when-to-use, when-not-to-use, or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct step in the CTP tool generation workflow: full creation, implementation, testing, duplicate search, and validation. There is no overlap in purpose.
All tool names follow a consistent pattern: 'ctp_' prefix followed by verb_noun (e.g., create_tool, generate_implementation). No mixing of styles.
With 5 tools, the server covers the essential stages of tool generation without being bloated. Each tool is necessary and well-scoped.
The tools cover creation, implementation, testing, validation, and duplicate detection. A list or delete tool might be useful but is not critical for the generator's purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give any MCP-compatible AI assistant a builder for live, hosted web tools and workflows.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
33 tools that make AI write, implement, and verify intent against explicit, testable constraints.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/titan-alpha/ctp-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
