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., "@Quire MCP Create a new Quire project called my-catalogue in my Documents folder"
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.
Quire is an open source digital publishing tool developed by Getty for creating beautiful, scholarly publications in multiple formats such as web, print and e-book. Optimized for visual imagery and designed to be widely accessible.
Related MCP server: any-cli-mcp-server
Quire MCP leverages the Model Context Protocol (MCP) to let you interact with Quire through natural language conversation, without needing to use the terminal directly. For example, you can prompt claude to:
"Create a new Quire project called my-catalogue in my Documents folder"
and Claude Desktop will handle the rest.
Note: Quire MCP is currently a work in progress. Phase 1 focuses on core CLI tooling. Contributions and feedback are welcome.
Node.js 18+
npm
quire CLI installed
Claude Desktop
Visit the official Quire repository and follow the instructions for your operating system: 🔗link.
Confirm Quire CLI is accessible: quire --version
Download the latest release from Claude: 🔗link
Through your terminal or IDE of choice, navigate to path where this repo is cloned and run the following commands:
Build: npm run build
Run the server: npm run
You need to register the MCP server with Claude Desktop by editing its config file.
~/Library/Application Support/Claude/claude_desktop_config.json
C:\\Users\\YOUR_USERNAME\\AppData\\Roaming\\Claude\\claude_desktop_config.json
Note: If the file does not exist, create it with the filename: claude_desktop_config.json
Add the following to the config file:
{
...
"mcpServers": {
"quire": {
"command": "node",
"args": ["/absolute/path/to/qr-mcp-server/build/index.js"],
"env": {
"PATH": "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin"
}
}
}
...
}The PATH value tells Claude Desktop where to find npm and npx. It varies depending on how Node was installed on your system.
Run the following in your terminal to find the correct value:
MacOS/Linux
echo $PATHWindows
echo %PATH%Copy the output and replace the PATH value in the config above with your own.
Setup | PATH to add |
Homebrew (macOS) | /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin |
nvm | ~/.nvm/versions/node/v20.x.x/bin:/usr/bin:/bin |
Windows | C:\Program Files\nodejs |
Note: If you're unsure which applies to you, run which npx (macOS/Linux) or where npx (Windows) in your terminal.
This returns the full path to the binary:
e.g. /opt/homebrew/bin/npx
Remove the /npx from the filename and insert the remaining path to your PATH config.
e.g. /opt/homebrew/bin
Replace /absolute/path/to/quire-mcp/index.js with the actual path on your machine. After saving and restarting Claude Desktop, you should see the 🔨 Icon in the chat interface including the Quire tools which are available.
Runs the Build command to generate html site files
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | No | Name of the quire project to build. Combined with projectPath treated as the parent folder. Projectname as they project directory. | |
| projectPath | No | Path to the quire project directory or when combined with projectName, the parent directory containing the project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility. It does disclose the main behavior (running a build and generating HTML site files), which implies a write/side-effect operation, but it does not mention whether existing output is overwritten, whether a project must already exist, or what a successful run returns.
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 sentence that communicates the action and outcome with no filler. The key verb 'Runs' is front-loaded and the purpose follows immediately.
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 annotations and no output schema, this minimal description leaves important context unstated: the project must already exist, the build may overwrite html output, and there is no mention of expected errors or success signals. For an agent deciding whether and how to invoke this mutation-like tool, the description is incomplete.
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 baseline is 3 even though the description adds no parameter-specific detail. The schema's parameter descriptions are present, though somewhat awkwardly worded, so the description itself does not need to compensate.
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 action ('Runs the Build command') and its purpose ('generate html site files'), making it clear this tool compiles a Quire project into static HTML. This naturally distinguishes it from siblings that create, preview, or stop previews.
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 create_new_quire_project, preview_quire_project, or stop_quire_preview. The agent must rely on sibling names and inference rather than any explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Quire project in the current directory or specified folder
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | The folder where the project should be created (defaults to the user's quire-projects directory) | /root/Documents/quire-projects |
| projectName | Yes | The name of the new quire project | |
| starterTemplate | No | The starter template to use for the new project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It adds location context but does not disclose filesystem side effects, whether an existing folder is reused or overwritten, whether directories are auto-created, or how the starterTemplate parameter affects the resulting project.
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, front-loaded sentence with no filler. It immediately states the action and the location scope, and 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 creation tool with no output schema and no annotations, the description plus schema gives the essential call shape. However, it never states what a successful creation returns, whether the project folder must already exist, or how this tool fits into the preview/build workflow implied by the sibling tools.
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 already documents all three parameters with 100% coverage, so the baseline is 3. The description adds only a slight nuance about 'current directory' versus the folder parameter, but it does not explain projectName or starterTemplate beyond what the schema already provides.
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 opens with a specific verb and resource: 'Create a new Quire project.' It also states the location scope ('current directory or specified folder'), which makes the tool's purpose concrete and clearly distinct from the sibling tools, which are all about previewing, building, or stopping previews.
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 given about when to use this tool versus the siblings. The usage context is only implied by the word 'create,' and there are no prerequisites, follow-up steps, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the Preview command to generate the html site files and start a local server. Typically port 8080.
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | No | The name of the quire projec to preview. Combined with projectPaht treated as the parent folder. | |
| projectPath | No | The path to the quire project directory or when combined with projectName, the parent directory containing the project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose two meaningful side effects: generating HTML files and starting a local server on port 8080. However, it omits whether the server runs continuously, blocks the command, or needs to be stopped explicitly, which is important for a server-starting 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 one tightly written sentence with no filler. It front-loads the core action ('Runs the Preview command') and adds the two most useful details: generated output and the local server port.
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?
The description covers the core action and even mentions the port, which is helpful. However, it lacks lifecycle context: the server presumably keeps running and should be stopped with stop_quire_preview, and there is no mention of what success looks like. Given the simple schema and sibling visibility, this is adequate but not fully 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 description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond the schema, but it does not need to because the schema already explains projectName and projectPath reasonably well.
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 action ('Runs the Preview command') and its concrete effects: generating HTML site files and starting a local server. It also gives a distinguishing detail ('Typically port 8080') that separates it from build_quire_project, which would not start a server.
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 does not say when to choose this tool over its siblings, nor does it mention stop_quire_preview as the way to halt the server it starts. The intended use is implied by the name and action, but no explicit guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stops the currently running quire preview process, if any.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly states the action and the idempotent edge case ('if any'), which is valuable. It does not detail termination semantics or side effects, but for a zero-parameter stop command that is a minor gap.
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 one short, front-loaded sentence with no filler. Every word contributes to specifying the action, the target resource, and the conditional behavior.
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 no-parameter, no-output-schema command, the description is nearly complete: it states what happens and the no-process case. It could mention return behavior or effects on the underlying process, but those are low-value details for this simple 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 zero parameters, so the schema is effectively exhaustive. The description does not need to explain parameter behavior, and the baseline of 4 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 uses a specific verb ('Stops') and a specific resource ('the currently running quire preview process'), which clearly states the tool's purpose. The 'if any' qualifier adds scope, and the action is clearly distinct from sibling tools like preview_quire_project or build_quire_project.
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 phrase 'currently running ... if any' gives a clear precondition: invoke this only when a quire preview process exists, and it is safe to call even if none is running. It does not explicitly name alternatives or exclusion scenarios, so it is slightly below full routing guidance.
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. Dates show when Glama detected each change.
v1.0.4build_quire_projectcreate_new_quire_projectpreview_quire_projectstop_quire_previewEach tool targets a distinct lifecycle step: create project, stop preview, build site, and preview site. Build and preview both generate HTML, so they could be confused, but preview's server behavior and description clarify the distinction.
Most tools follow a clear verb_quire_target pattern, such as stop_quire_preview, build_quire_project, and preview_quire_project. create_new_quire_project breaks the pattern slightly with an extra 'new', but the intent is still clear.
With only four tools, the set is compact and well-scoped to the main Quire operations. Each tool serves a necessary purpose without redundancy.
The core Quire workflow is covered: create a project, preview it, build the site, and stop the preview server. There is no status, clean, or listing command, but those are not essential for a minimal local-site-generation MCP server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Interact with the Stitch API using natural language commands.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Interact with your Google Cloud Firestore resources using natural language commands.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/andy-jdl/quire-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
