Click on "Deploy 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., "@AI Workbench MCP show me the available prompt templates and assistant blueprints"
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.
Never used MCP before? Start with the Beginner Guide: what MCP is, why these three tools exist, exact install/doctor steps, expected results and failure paths.
AI Workbench MCP exposes a small local catalog over Model Context Protocol stdio. It is intentionally boring in the best way: no network calls, no shell execution, no account access, no file writes, no hidden provider request.
It gives an MCP host three tools:
Tool | Result |
| Lists the bundled prompt templates and assistant blueprints |
| Fills a bundled prompt template with explicit string variables |
| Returns one assistant blueprint for ChatGPT, Claude, Gemini, Grok, or portable Agent Skill format |
A lot of AI repos jump straight from "here is a prompt" to "this is an agent." I wanted a smaller boundary that is easy to inspect.
The server keeps the useful parts local and makes its limits obvious:
read-only tool contracts;
explicit MCP trust hints;
bounded input sizes;
strict top-level schemas;
no runtime dependencies outside the Python standard library;
real stdio handshake tests;
named tests for every public tool.
Related MCP server: MCP Inspector as MCP Server
Install the published alpha package:
python -m pip install "alptugharun-ai-workbench-mcp==0.1.0a2"Confirm the local package can load before touching host configuration:
alptugharun-ai-workbench-mcp --doctorA healthy result reports the package/Python versions, all three tool names, catalog counts and the read-only permission boundary. It makes no network request and does not prove host compatibility; it tells you whether the local package layer is healthy.
Then point a stdio-capable MCP host at the server:
Launch command:
alptugharun-ai-workbench-mcpThis repository documents the stdio server itself. For the host we have actually exercised, use the copy/paste Cursor setup and 3-tool verification guide. Other MCP clients can differ, so use their current documentation rather than assuming Cursor's configuration is portable.
Every public tool declares:
{
"readOnlyHint": true,
"destructiveHint": false,
"idempotentHint": true,
"openWorldHint": false
}The implementation does not import HTTP clients, subprocess modules, filesystem-write helpers, browser libraries, or provider SDKs.
That does not mean "trust any MCP server." It means this repository keeps its own boundary narrow and testable.
python -m unittest discover -s tests -v
python examples/smoke_client.pyCI runs the package and protocol tests on Linux and Windows.
PyPI: the project publishes through GitHub OIDC Trusted Publishing and the release workflow signs the wheel with keyless Sigstore. Version 0.1.0a2 adds the local --doctor / --version first-run diagnostics; use the PyPI badge above to confirm the release is available before installing that exact version.
A clean Windows virtual environment installed the exact PyPI version successfully, negotiated MCP protocol 2025-06-18, listed all three tools, completed successful render_prompt and get_assistant calls, and returned a bounded error for an unknown tool.
Official MCP Registry: io.github.alptugharun/ai-workbench-mcp is published and currently reports active in the production registry.
Real-host verification: a maintainer-run Cursor 3.20.21 session invoked list_prompts, render_prompt and get_assistant successfully against the published package. This is host evidence, not an independent third-party endorsement or a universal compatibility claim.
See REGISTRY-PUBLISHING.md, HOST-VERIFICATION.md and the failure-first Troubleshooting ladder.
Small, reproducible improvements are welcome. The most useful contributions right now are:
real MCP host verification;
protocol edge-case tests;
clearer failure messages;
documentation corrections;
narrowly scoped catalog improvements.
Please read CONTRIBUTING.md before opening a PR. If the server works in a host we have not independently verified yet, a reproducible host report is more valuable than a generic “works for me.”
This project was extracted from AI Social Media Toolkit so the MCP server can evolve as a focused product instead of being buried inside a larger creator/AI repository.
Built by Alptuğ Harun.
If the server gives you a useful first result, starring the repository helps other MCP users discover it. If it fails, open a reproducible report instead — failures with environment details improve the project faster than vanity metrics.
MIT — see LICENSE.
Return one bundled assistant blueprint formatted for a selected host. This does not create, install, publish, or modify an assistant account.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Assistant ID returned by list_prompts. | |
| target | Yes | Host format for the returned instruction blueprint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's negative clause ('does not create, install, publish, or modify') reinforces that but adds no genuinely new behavior such as auth requirements, caching, or output shape.
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?
Two short sentences, the positive purpose front-loaded and the negative disambiguation second. No filler, no repetition of the title.
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?
For a read-only, idempotent two-parameter tool with full schema coverage and no output schema, this covers what the tool is and is not. The remaining gap is that the returned blueprint's structure is only vaguely characterized, which matters since there is no output schema to document it.
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 the enum for target is fully documented, so the schema carries the parameter burden. The description echoes the host-format concept ('formatted for a selected host') but adds no syntax or constraint details beyond what is already present.
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?
States a specific verb and resource ('Return one bundled assistant blueprint') and names the target dimension, so the agent knows it produces a host-formatted artifact rather than a listing. It is less explicit about how it differs from the sibling render_prompt, which is the only real ambiguity.
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?
Usage is only implied: fetch a single assistant blueprint by id for a given host. No statement of when to prefer this over render_prompt or list_prompts, and no prerequisites (e.g., that the id must come from list_prompts — that hint lives in the schema, not the description).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the bundled prompt templates and assistant blueprints available in this local catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, covering the safety profile fully. The description adds only the 'local catalog' framing, which reinforces the closed-world nature but provides little beyond the structured data. No return shape or rate/limit context is given.
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?
A single front-loaded sentence naming the verb and both resource types with zero filler. Every word earns its place.
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?
For a parameterless, read-only listing tool whose annotations already carry the behavioral profile, the description is nearly sufficient. With no output schema, it could briefly note what each listed entry contains, but the core intent is 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?
The tool takes zero parameters, so per the rubric the baseline is 4 and no parameter documentation is required. The description does not need to compensate for anything schema-wise.
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 a specific verb (List) and precise resources (prompt templates and assistant blueprints) scoped to a local catalog, so its function is unambiguous. It does not, however, name the sibling tools render_prompt or get_assistant to sharpen the distinction, leaving that differentiation to inference.
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?
There is no explicit statement of when to use this versus render_prompt or get_assistant, nor any prerequisites. Usage is only implied: an agent would reasonably list the catalog before fetching or rendering an item, but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render one bundled prompt template using supplied string variables. Returns text only and does not call an AI provider.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Prompt ID returned by list_prompts. | |
| variables | Yes | Exact template variables as non-empty strings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: output is text only and no AI provider is invoked, which clarify the side-effect-free, local nature of the call.
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?
Two short sentences, zero filler, with the core action stated first and the return/behavioral caveat second. Every clause earns its place.
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?
Despite no output schema, the description states the return type (text only) and disclaims AI-provider invocation, while annotations cover the safety profile and the schema fully documents both parameters. Nothing essential for correct invocation is missing.
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 id and variables parameters are already documented, including that variables are non-empty strings. The description's 'using supplied string variables' adds only marginal reinforcement, so the baseline 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?
States a specific verb (Render) and resource (one bundled prompt template) with scope, so it reads clearly against list_prompts and get_assistant. An agent can identify that this produces rendered text from a template without opening the schema.
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?
Use is implied by the description (render a template you have an id for), but there is no explicit when-to-use, when-not-to-use, or reference to the sibling alternatives (e.g., pairing with list_prompts to get ids). Adequate but leaves routing to inference.
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.
v0.1.0get_assistantlist_promptsrender_promptScored across 3 tools
Each tool targets a distinct action and resource: list_prompts enumerates the catalog, render_prompt renders a specific template, and get_assistant retrieves a blueprint. The list vs get distinction is clear, with no overlapping purposes.
All names follow a consistent verb_noun snake_case pattern: list_prompts, render_prompt, get_assistant. Pluralization varies logically (list many vs render/get one), but the convention is uniform.
Three tools are well-suited to a read-only local catalog, covering the essential operations of enumerating, rendering, and retrieving. The count is minimal but each tool earns its place, with no bloat or missing core function.
The surface covers listing, rendering, and retrieving, but lacks a direct way to get a raw prompt template without rendering it (e.g., get_prompt) or a generic assistant blueprint without host selection. These are minor gaps for a small catalog that agents can likely work around.
Illumora Craft — evidence-augmented prompt compile for agents via remote MCP (OAuth) or local stdio.
Manage portable AI agent playbooks, Agent Skills, MCP configurations, personas, and memory.
Self-hosted AI prompt library: prompts, collections, tags, teams, chains. 29 MCP tools for agents.
Generate contextual prompts and reusable agent skills, evaluate prompts with the 16-dimension Prompt Score, and manage saved work in PromptDrive. Twelve MCP tools also provide authorized access to private Memory for source-grounded answers. Connect over Streamable HTTP using OAuth 2.1 and PKCE. Generation consumes account quota and automatically saves successful results; Memory access follows account permissions and plan limits.
