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., "@InkRoom Prompts MCP Find warm café poster prompts with example images"
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.
This is the standalone InkRoom Prompts MCP distribution, exported one way from the official prompts-v1.0.4 source. Runtime version: 1.0.4. Runtime and license bytes are preserved; development stays in the canonical repository. See source provenance, installation and update policy.
Official prompt tools / 官方提示词工具 · Usage / 使用文档
Image prompt inspiration, without an account or API key.
Hosted prompt tools: use the official tools and documentation linked above. The MCP package runs locally over STDIO or loopback HTTP; no public Remote MCP endpoint is announced.
Ask your assistant: “Find warm café poster prompts with example images.”
Search public, approved prompt-library records; get the complete prompt, its original example image and source.
If a successful search has no match, ask InkRoom's configured text model to turn the idea into a usable prompt. Optimized prompts have no example image.
No account, login, Key, Token, subscription or paid-image authorization. Free usage is subject to server limits.
MIT-licensed MCP server and Agent Skill. The license does not cover third-party prompt/image content or other InkRoom code outside this directory.
Requires Node.js 20.3+. The ASCII server ID is inkroom-prompts.
Install from this product distribution repository:
git clone https://github.com/InkRoom-AI/inkroom-prompts.git
cd inkroom-prompts
npm ci --ignore-scripts
node src/cli.mjs --helpThe canonical development source remains InkRoom-AI/inkroom-client/prompts. No .env or credentials are needed.
After downloading the GitHub release package, use this portable STDIO configuration in clients that support mcpServers:
{
"mcpServers": {
"inkroom-prompts": {
"command": "npx",
"args": ["-y", "--package", "https://github.com/InkRoom-AI/inkroom-client/releases/download/prompts-v1.0.4/inkroom-prompts-1.0.4.tgz", "inkroom-prompts"]
}
}
}The release archive is distributed on GitHub, not the npm registry. For source installations, use node with the absolute path to src/cli.mjs instead. Clients that use a different configuration format must map the same command and argument array to their MCP settings; do not add authentication fields.
For a local Streamable HTTP connection:
node src/cli.mjs --http 8788Connect to http://127.0.0.1:8788/mcp without headers. The listener binds only to loopback. No official public Remote MCP URL is announced for this local package. Operators deploying behind TLS must validate the public Host/Origin, set trusted proxies correctly, enforce ingress limits and complete live acceptance first.
Related MCP server: PromptingBox MCP Server
Copy the entire skills/inkroom-prompts directory into the client’s Skill directory or import its ZIP when supported. It follows the Agent Skills format. It works independently of the paid inkroom Skill and has no runtime dependency on the MCP SDK.
With the Skill selected, ask:
“帮我找几个暖色咖啡馆海报提示词，带示例图。”
“Improve this product-photo idea into a prompt; keep the label text unchanged.”
The Skill uses the MCP tools when available, otherwise its bundled Node.js script.
Tool | Input | Result |
| No parameters | Local capability and cost-boundary help; no network or model call |
| No parameters | Public InkRoom model names, parameters and official sale prices; no account authorization implied |
|
| Complete public prompts with their paired example URLs and source links |
|
| One AI-optimized prompt, model, and |
The MCP uses the official TypeScript SDK, standard tool annotations, structured JSON and image resource_link entries. The host decides whether links render inline. It does not download images or claim that a link was displayed or saved.
Search first, then optimize on a successful empty result, or optimize directly on an explicit rewrite request. Network/catalog errors are not empty results. There are no hidden paid-generation calls, automatic model switches or optimization retries.
The implemented server policy is shared across replicas and restarts:
30 total operations per IP per minute; global ingress 600 per minute.
Optimization: 3 per IP per minute, 10 per IP per day, 30 globally per minute and 500 per day. These are shared request-count limits, not a monetary budget.
Daily windows reset at 00:00 Beijing time (UTC+8). IPv6 addresses share a /64 quota. Shared VPN/cloud egress may share an IP allowance; this is not a guaranteed per-device entitlement.
HTTP 429 includes Retry-After. Wait rather than changing identity or splitting work.
Optimization is an internal platform call, using an operator-selected text model (default gpt-6.1-sol) on an existing enabled channel. Retail pricing is not required. Failed or unknown attempts still count toward the request limits, including across replicas and restarts.
Free means no deduction from the user's credits or balance; it does not mean the model supplier charges nothing. The existing internal-use ledger records actual reported token usage. Missing supplier usage remains unknown rather than being estimated or presented as zero cost.
npm ci --ignore-scripts
npm test
npm pack --dry-runTests cover real SDK initialization and tool calls, STDIO, Streamable HTTP, errors, cancellation, no credential forwarding, image/source pairing and response limits. Backend integration and quota tests are described in backend/README.md. Mock-model tests do not prove hosted model availability.
The canonical repository also mirrors this Skill at its top-level skills/inkroom-prompts. This distribution retains the exact released Skill under the same relative path.
The MCP and Skill both call https://prompts.inkroom.ai for free search and text optimization. The backend runs in its own inkroom-prompt-assistant container; it does not fall back to the paid image API. Website pages stay on inkroom.ai, and library examples stay on static.inkroom.ai. This domain is the release target; hosted availability still requires live acceptance.
The canonical repository marketplace includes a separate inkroom-prompts plugin rooted in prompts/. It combines the free local STDIO MCP and the inkroom-prompts Skill. It does not change the paid inkroom plugin. Marketplace review and actual Cursor installation are separate states; do not treat this source package as an approved listing.
Plugin distribution version: 1.0.4; pinned MCP runtime: 1.0.4.
Requires Node.js 20.3+ and internet access. The MCP starts with npx using the existing public GitHub release TGZ.
No account, API key, MCP Token, plugin secret, or paid image-generation setup is required. The service has shared request-count limits.
Tools: help, list_models, search_prompts, and optimize_prompt. Optimization may cost the platform money; no model call runs during installation. Follow the included Skill before calling tools.
Official tools: https://inkroom.ai/tools/prompts . Documentation: https://inkroom.ai/tools/prompts/docs . Privacy: PRIVACY.md.
No hooks, background jobs, telemetry, or credentials are included. Disable or uninstall the plugin through Cursor to remove this integration; preserve unrelated MCP connections.
The Dockerfile packages the same keyless 1.0.4 MCP implementation. Build from this directory with docker build -t inkroom-prompts:1.0.4 ., then configure your MCP client to run docker run --rm -i --read-only --cap-drop=ALL --security-opt=no-new-privileges inkroom-prompts:1.0.4. No port, volume, API key or MCP Token is required. Network access is needed for public prompt searches and capped text optimization. The image runs as the unprivileged node user.
Container initialization, tool discovery, invalid-input/offline errors and one anonymous public prompt search were verified on Linux/amd64 with Node v22.23.3. The base image is pinned by digest. Container protocol validation does not establish Docker Catalog approval or native Docker Desktop Toolkit installation; those statuses are tracked separately. Other CPU architectures have not been tested.
Adds local help and anonymous list_models (official InkRoom sale prices) alongside search_prompts and optimize_prompt. Read-only catalog/help/search needs no Key and never starts optimization or generation. Explicit invalid credentials are never silently retried as anonymous. Existing prompt search, optional test origin and optimization limits remain unchanged. Native desktop host installation and registry approval are separate acceptance states.
Read local capability and cost-boundary descriptions without parameters, credentials, network requests or upstream model tokens. This static help does not check service health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, closed-world, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: no credentials, no network requests, no upstream model tokens, and no service-health check, which helps the agent understand cost and side-effect boundaries.
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 two clear sentences with no wasted words. It front-loads the core capability and then immediately clarifies the static, non-health-checking nature.
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 zero-parameter static help tool with no output schema, the description provides enough behavioral context to call it correctly. It could optionally state what kind of descriptions are returned, but nothing essential 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?
The schema has zero parameters and 100% coverage, so the baseline is 4. The description reinforces that no parameters are accepted, which is consistent with the empty schema.
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 a specific action and resource: reading local capability and cost-boundary descriptions, with the explicit qualifier that it is static help. It distinguishes itself from dynamic or service-dependent tools by saying it does not check service health, though it does not directly name the sibling tools.
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 appropriate use by emphasizing static, local, credential-free, and network-free behavior, and it excludes health-checking. However, it does not explicitly say when to choose this over list_models or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the main InkRoom public MCP catalog for current model names, parameters and InkRoom official sale prices. No Key, Token, Cookie, upstream model invocation or optimization. Listed models do not grant account authorization. Network and rate-limit failures remain errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds valuable context the annotations don't carry: no key/token/cookie required, the listing does not grant account authorization, and network/rate-limit failures surface as errors rather than empty results. It stops short of describing pagination or result 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?
The purpose is front-loaded in the first sentence and the negative constraints follow compactly. The final clauses are somewhat rapid-fire but each conveys a distinct constraint, so little is wasted.
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?
With no parameters and no output schema, the description carries the burden of explaining what comes back, and it names the fields (model names, parameters, prices) reasonably well. It could say more about the response format, but the essentials for calling it correctly are present.
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 the baseline of 4 applies. The description correctly implies a no-input call and explains that no credentials are needed.
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 — querying the public model catalog for names, parameters, and official sale prices. It is clearly distinguishable from the siblings (help, search_prompts, optimize_prompt) by domain, though it doesn't explicitly reference them.
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 this is the read-only catalog lookup and rules out invocation and optimization, which hints at what it is not for. However, it never states when to prefer it over alternatives or under what circumstances an agent should call it rather than help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn an image idea into a usable prompt with InkRoom’s configured text model. Use after a successful search finds no match or when explicitly asked to rewrite. Free within server limits; never generates or includes an example image. No automatic retries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful context beyond annotations: cost ('Free within server limits'), output nature ('never generates or includes an example image'), and retry behavior ('No automatic retries'). These are useful operational details not covered by readOnly/openWorld/idempotent/destructive hints.
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?
Three tightly constructed sentences with zero waste. Purpose is front-loaded, followed by usage trigger and behavioral constraints.
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 low-complexity tool with one parameter, no output schema, and rich annotations, the description covers purpose, usage, cost, output constraints, and retry behavior. Minor gap: it does not explicitly state that the return value is a text prompt, though 'never generates or includes an example image' strongly implies 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?
With 0% schema description coverage, the description must explain the single 'query' parameter. It implies the query is the image idea ('Turn an image idea into...'), but does not clarify format, length limits (max 500 chars), or whether it should be a raw idea versus a structured description.
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: 'Turn an image idea into a usable prompt with InkRoom’s configured text model.' It also distinguishes itself from search_prompts by specifying it should be used after a search finds no match.
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?
Gives a clear triggering condition: 'Use after a successful search finds no match or when explicitly asked to rewrite.' This implicitly names search_prompts as the alternative, but does not explicitly state when not to use it (e.g., when a search match exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public InkRoom image prompts using up to 3 keyword groups. Returns complete prompts, original example image links and provenance. No login or Key. A search error is not an empty result.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: no authentication required, and the important caveat that a search error must not be treated as an empty result, which affects how the agent should handle failures.
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?
Three tight sentences with no filler: what it searches, what it returns, and the auth/error caveats. The key information 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?
With no output schema, the description appropriately summarizes return content (complete prompts, example image links, provenance) and covers auth and error handling. The only gap is the undocumented limit parameter.
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 0%, so the description must compensate. It clarifies that query is composed of up to 3 keyword groups, which adds real meaning, but the limit parameter (default 3, range 1-5) is never explained in the description or schema.
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 ("Search public InkRoom image prompts"), plus scope ("up to 3 keyword groups") and what comes back. It is clearly distinguishable from siblings help, list_models, and optimize_prompt.
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 implied by the name and by "No login or Key", and the note "A search error is not an empty result" tells the agent how to interpret failures. However, it never says when to choose this over a related tool like optimize_prompt, nor any exclusions.
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.
v1.0.4helplist_modelsoptimize_promptsearch_promptsScored across 4 tools
Each tool targets a distinct capability: help returns static docs, list_models queries the catalog, search_prompts searches prompts, and optimize_prompt rewrites an idea into a prompt. The only mild overlap is between help (capability descriptions) and list_models (model/price catalog), but the descriptions clearly delineate them.
Three tools follow a clear verb_noun snake_case pattern (list_models, search_prompts, optimize_prompt). The lone 'help' is a bare noun, a minor but readable deviation from the otherwise consistent convention.
Four tools is on the lean side but well-matched to a focused prompt-search/optimization service; each tool earns its place. It is not thin enough to feel incomplete, though a fifth (e.g., fetch-by-id or category browse) would round it out.
The surface covers discovery (search_prompts returns full prompts and provenance), catalog lookup (list_models), rewrite (optimize_prompt), and self-documentation (help). Minor gaps exist—no direct fetch-by-id, pagination, or filter-by-model—but agents can work around them via keyword search.
Community library of composable AI prompt blocks for search, composition, and contribution.
A prompt engineer you talk to. It writes prompts, sharpens yours, and keeps them on your shelf.
Search attributed image prompts, retrieve full templates, and browse GPT Image Hub categories.
Your prompt library in any MCP client: list, fetch, save and version prompt templates.
