The 智睦云打印 MCP server enables cloud printing capabilities, allowing you to manage printers, upload files, and submit print jobs through an AI assistant.
Check Environment (check_install_progress): Verify whether your cloud print environment is fully configured and ready to use.
List Printers (query_printers): Retrieve a list of all available printers under your account, including their online status and control IDs.
Query Printer Details (query_printer_detail): Get detailed capability information for a specific printer or shared device by printer name, share serial number, or device type.
Upload Files (upload_file): Upload a local file to the cloud and receive a public URL suitable for printing.
Create Roaming Print Task (create_roaming_task): Submit a document (PDF, PNG, JPG, WORD, EXCEL, PPT, etc.) into a print queue as a roaming task using a public URL.
Update Duplex/Simplex Setting (update_printer_side): Modify a roaming task's print side — single-sided (ONESIDE), duplex long-edge (DUPLEX), or duplex short-edge (TUMBLE).
Update Color Mode (update_printer_color): Change a roaming task's color setting to color (COLOR) or black-and-white (MONOCHROME).
Update Copy Count (update_printer_copies): Set the number of copies for a roaming task (must be ≥ 1).
Update Paper Size (update_printer_paper): Change the paper size using preset names (A3, A4, A5, Letter, Legal, etc.) or custom width/height in millimeters.
Direct Print (direct_print_document): Send a document immediately to a specified printer using the printer's name and control serial number.
webprinter_mcp is an MCP Server for cloud printing.
If your MCP client supports stdio type MCP, you can use it to perform file uploads, query printers, submit print tasks, and print directly.
You can think of it as a "tool that handles print tasks for you."
For example, you can say to an AI connected to this MCP:
"Check if there are any available printers."
"Upload this file, get it ready for printing."
"Add this file to the print queue."
"Print directly to the office printer."
"Change the previous task to double-sided."
Related MCP server: Memobird MCP Server
You need to install the Zhimu Cloud Print server and share your printer. Please get the installation package from Zhimu Cloud Print:
https://any.webprinter.cn
Then, you need to obtain a cloud print access token.
Get it here:
[https://any.webprinter.cn/get-ai-server-token](https://any.webprinter.cn/get-ai-server-token)
After getting the token, set the environment variable:
WEBPRINTER_ACCESS_TOKEN: Required
pip install webprinter_mcppip install .If you just want to confirm it can start locally, you can run:
webprinter_mcpOr:
python -m webprinter_mcpNote: This command usually does not output prompt information after starting.
It enters a state waiting for an MCP client connection, which is normal.
This project is better suited for stdio connection.
If you have already installed this package on your machine, it is recommended to configure it like this:
{
"type": "stdio",
"config": {
"mcpServers": {
"webprinter": {
"type": "stdio",
"command": "webprinter_mcp",
"args": [],
"env": {
"WEBPRINTER_ACCESS_TOKEN": "your-access-token"
}
}
}
}
}If your client supports npx style, you can also configure it like this:
{
"type": "stdio",
"config": {
"mcpServers": {
"webprinter": {
"type": "npx",
"command": "npx",
"args": ["-y", "webprinter_mcp"],
"env": {
"WEBPRINTER_ACCESS_TOKEN": "your-access-token"
}
}
}
}
}Note: If you use npx webprinter_mcp, you still need a working Python environment on your machine.
mcpServers configurationIf your MCP client accepts the mcpServers structure directly, you can use the following configuration:
{
"mcpServers": {
"webprinter": {
"args": [
"-y",
"webprinter_mcp"
],
"command": "npx",
"env": {
"WEBPRINTER_ACCESS_TOKEN": "your-access-token"
},
"type": "npx"
}
}
}Where:
WEBPRINTER_ACCESS_TOKEN
Needs to be obtained from https://any.webprinter.cn/get-ai-server-token first
command and args
Indicates starting the MCP Server via npx webprinter_mcp
type
Indicates that the current client uses the npx method
This MCP Server provides the following tools:
check_install_progress
Checks if the current account and device environment have cloud printing capabilities
query_printers
Queries the list of printers available to the current account
query_printer_detail
Queries detailed capability information for a specific printer or shared device
upload_file
Uploads a local file and returns a public URL that can be used for printing
create_roaming_task
Creates a roaming print task based on a file URL
update_printer_side
Modifies the single/double-sided settings of a roaming print task
update_printer_color
Modifies the color/monochrome settings of a roaming print task
update_printer_copies
Modifies the number of copies for a roaming print task
update_printer_paper
Modifies the paper size for a roaming print task, supporting presets like A3, A4, etc., as well as custom dimensions
direct_print_document
Sends a file directly to a specified printer for printing
You can also think of it as a complete printing workflow capability:
Check environment: check_install_progress
View printers: query_printers / query_printer_detail
Upload file: upload_file
Create roaming print: create_roaming_task
Adjust task parameters as needed: update_printer_side / update_printer_color / update_printer_copies / update_printer_paper
Or print directly: direct_print_document
Each tool is described below by "Purpose, Behavior, Key Parameters, and Usage Suggestions" for easy display in MCP platforms, directories, and documentation.
check_install_progressPurpose
Check if the current account, client, and printing environment have available cloud printing capabilities
When to use
Call first during initial setup
Call first when encountering printing issues, inability to find printers, or failed task submissions
Behavior
Queries the cloud printing platform for current installation and configuration status
Does not modify any print tasks
Parameters
None
Return result
Returns the current environment check result, usually used to determine if client, device, or sharing configuration is complete
Usage suggestion
Recommended as the first step in all printing workflows
Example phrasing
"Check if the current environment can use cloud printing"
query_printersPurpose
Query the list of printers available under the current account
When to use
When the user wants to view available printers
Before direct printing to confirm if the target printer exists
Behavior
Returns a list of printers
Hidden printers are marked as supporting only roaming print tasks
Parameters
None
Return result
Common fields include printer name, alias, online status, control terminal ID, hidden status, etc.
Usage suggestion
If the user says "print to a certain printer," it is recommended to call this tool first to confirm the device name and control ID
Example phrasing
"Show me the available printers"
query_printer_detailPurpose
Query detailed capability information for a specific printer or shared device
When to use
When the user needs to confirm device capabilities
Before printing to confirm device type, share ID, or detailed parameters
Behavior
Returns detailed information based on printer name, share ID, or device type
Parameters
printer_name
Printer name, optional
share_sn
Shared device ID, optional
device_type
Device type, optional, supports printer, scanner, camera
Return result
Returns detailed capability or configuration data for the specified device
Usage suggestion
Provide at least one filter condition to avoid an overly broad query
Example phrasing
"Check what capabilities the front desk printer supports"
upload_filePurpose
Upload a local file and exchange it for a public URL usable for subsequent printing
When to use
When the source file is on the local disk
Before roaming or direct printing when there is no public file URL yet
Behavior
Reads the local file and uploads it to the cloud
Returns a file URL that can be read by the print service
Parameters
file_path
Local file path, required
Return result
Returns uploaded file information and accessible URL
Usage suggestion
If the file is already a public URL, you can skip this step
Example phrasing
"Upload the PDF on my desktop and give me a printable URL"
create_roaming_taskPurpose
Create a roaming print task, putting the file into the print queue for later processing
When to use
When the user wants to generate a print task first instead of printing immediately to a specific device
Behavior
Creates a roaming print task based on file name, file URL, and file type
Returns task ID upon success
Parameters
file_name
File display name, required
url
Public file URL, required
media_format
File format, required, supports PDF, PNG, JPG, WORD, EXCEL, PPT, etc.
Return result
Returns the newly created roaming task ID
Usage suggestion
You need this task ID to modify single/double-sided, color, copies, or paper settings later
Example phrasing
"Submit this file as a roaming print task"
update_printer_sidePurpose
Modify the single/double-sided settings of a roaming print task
When to use
When the user explicitly specifies single-sided, double-sided, long-edge flip, or short-edge flip
Behavior
Updates the print side setting based on task ID
Parameters
task_id
Roaming task ID, required
side
Optional values: ONESIDE, DUPLEX, TUMBLE
Return result
Returns update result
Usage suggestion
Applicable to already created roaming tasks, not for direct print tasks
Example phrasing
"Change task 123 to double-sided printing"
update_printer_colorPurpose
Modify the color mode of a roaming print task
When to use
When the user explicitly specifies color, black and white, or grayscale printing
Behavior
Updates the color mode based on task ID
Parameters
task_id
Roaming task ID, required
color
Optional values: COLOR, MONOCHROME
Return result
Returns update result
Usage suggestion
When the user says "black and white printing," it should be converted to MONOCHROME
Example phrasing
"Change task 123 to black and white printing"
update_printer_copiesPurpose
Modify the number of copies for a roaming print task
When to use
When the user says "print 2 copies," "print 3 copies," etc.
Behavior
Updates the number of copies based on task ID
Parameters
task_id
Roaming task ID, required
copies
Number of copies, required, must be greater than or equal to 1
Return result
Returns update result
Usage suggestion
If the user does not explicitly state the number of copies, do not modify it arbitrarily
Example phrasing
"Change task 123 to print 3 copies"
update_printer_paperPurpose
Modify the paper size of a roaming print task
When to use
When the user specifies paper types like A3, A4, A5, Letter, etc.
When the user provides width and height directly
Behavior
Supports automatic conversion of standard paper names to millimeter dimensions
Also supports passing custom width and height directly
Parameters
task_id
Roaming task ID, required
paper
Can pass paper type name, e.g., A4
Can also pass an object, e.g., {"width": 210, "height": 297}
Return result
Returns update result
Usage suggestion
Width and height units are in millimeters
Currently supported presets include A0-A6, B4, B5, LETTER, LEGAL, TABLOID
Example phrasing
"Change task 123 to A4 paper"
"Change task 123 to paper with width 210 and height 297"
direct_print_documentPurpose
Send a file directly to a specified printer
When to use
When the user explicitly specifies printing immediately to a specific printer
Behavior
Initiates printing directly based on file information and target device information
If the target printer is a hidden printer, direct printing will be blocked, and the user will be prompted to use a roaming task instead
Parameters
file_name
File display name, required
url
Public file URL, required
media_format
File format, required
device_name
Target printer name, required
control_sn
Target printer control terminal ID, required
Return result
Returns direct print result
Usage suggestion
It is recommended to call query_printers first to confirm the target printer name and control terminal ID
If it is a local file, call upload_file first
Example phrasing
"Print this file directly to the front desk printer"
For first-time use, it is recommended to follow these steps:
You can think of it as:
"Check if the current environment can use cloud printing normally"
If the return shows that the client or device is not ready, complete the WebPrinter installation and sharing configuration first.
You can say:
"Show me what printers are available"
This step usually provides:
Printer name
Printer alias
Online status
Control terminal ID
You can think of it as:
"Upload this local PDF and give me a printable URL"
During local debugging, common parameters look like this:
{
"file_path": "C:\\\\docs\\\\report.pdf"
}If you just want to enter the print queue first, you can think of it as:
"Submit this file for roaming print" or
"Add this file to the print queue"
If you want to print to a specific printer immediately, you can think of it as:
"Print this file directly to the office HP printer"
The following phrases are well-suited for this MCP to handle:
"Check if the current cloud printing environment is usable"
"Show me what printers are available"
"Upload the PDF on my desktop"
"Add this webpage to the print queue"
"Print directly to the front desk printer"
"Change the previous task to double-sided"
webprinter_mcp?This is normal.
It will wait for the MCP client to connect via stdio after starting and will not print a lot of information like a regular command-line tool.
Please get the token here first:
[https://get-ai-token.webprinter.cn](https://any.webprinter.cn/get-ai-server-token)
Then confirm you have set:
WEBPRINTER_ACCESS_TOKEN
webprinter_mcp cannot be foundUsually, the Python Scripts directory has not been added to PATH.
In this case, you can use it directly:
python -m webprinter_mcpFor roaming print tasks that have already been created, you can continue to modify the following configurations:
update_printer_side(task_id, side)
update_printer_color(task_id, color)
update_printer_copies(task_id, copies)
update_printer_paper(task_id, paper)
task_id
Roaming print task ID
side
Optional values: ONESIDE, DUPLEX, TUMBLE
Representing: single-sided, double-sided long-edge flip, double-sided short-edge flip
color
Optional values: COLOR, MONOCHROME
Representing: color, black and white
copies
Integer
Must be greater than or equal to 1
paper
Can pass paper type name directly, e.g., A3, A4, A5, LETTER
Can also pass custom object: {"width": 210, "height": 297}
Width and height units are in millimeters
If you are calling via natural language in an MCP client, you can say:
"Change task 123 to double-sided printing"
"Change task 123 to black and white printing"
"Change task 123 to print 3 copies"
"Change task 123 to A4 paper"
"Change task 123 to paper with width 210 and height 297"
If you are debugging in a local CLI, you can use it like this:
python scripts/mcp_client.py update-printer-side --task-id 123 --side DUPLEX
python scripts/mcp_client.py update-printer-color --task-id 123 --color MONOCHROME
python scripts/mcp_client.py update-printer-copies --task-id 123 --copies 3
python scripts/mcp_client.py update-printer-paper --task-id 123 --paper A4
python scripts/mcp_client.py update-printer-paper --task-id 123 --width 210 --height 297Check whether the user's cloud print environment is fully configured.
| 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. While it implies a status check ('whether...fully configured'), it fails to specify the return format (boolean, percentage, list of missing components), caching behavior, or what criteria define 'fully configured.'
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 of nine words with no redundant information. It is appropriately front-loaded with the action verb and wastes no space on tautological restatements of the tool name.
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 zero parameters and no output schema, the description is minimally adequate for tool selection but leaves significant gaps. It does not explain what constitutes 'fully configured,' what the response structure looks like, or how this relates to the sibling printer management tools, which would be valuable given the lack of structured metadata.
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 zero parameters, which per the scoring rules establishes a baseline of 4. There are no parameters requiring semantic explanation beyond what the schema (empty properties object) already conveys.
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 the specific verb 'Check' and identifies the resource 'user's cloud print environment' with the scope 'fully configured.' It distinguishes from siblings like query_printers (which lists specific printers) by focusing on overall environment configuration status rather than individual device queries.
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 states what the tool does but provides no guidance on when to use it versus alternatives. It does not indicate whether this should be called before other operations, how it relates to query_printers, or prerequisites for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a roaming print task from a public document URL.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | ||
| url | Yes | ||
| media_format | Yes |
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 adds the constraint that the URL must be 'public,' but fails to disclose whether the operation is asynchronous, what the return value is (likely a task ID given the 'create task' naming), or how to check task status. It does not indicate if the operation is destructive or idempotent.
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 with no redundancy. However, given that all three parameters lack schema descriptions and no annotations exist, the description is underspecified. It prioritizes brevity over necessary detail, making it 'too concise' for the complexity of the tool.
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 mutation tool with three undocumented parameters, no annotations, and no output schema, the description is insufficient. It lacks guidance on the 'roaming' workflow, expected 'media_format' values, the purpose of 'file_name' when a URL is provided, and how to interpret or use the return value (presumably a task identifier).
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 0% description coverage for all three parameters (file_name, url, media_format). The description only partially compensates by implying the 'url' parameter requires a public document URL. It completely omits explanation of 'file_name' (is it a destination name or metadata?) and 'media_format' (expected values like 'A4', 'Letter', 'PDF'?).
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 ('Create') and resource ('roaming print task'), and includes the source ('public document URL'). The term 'roaming' helps distinguish it from the sibling 'direct_print_document', though it could further clarify what 'roaming' implies in this context.
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 siblings like 'direct_print_document' or 'upload_file'. It mentions 'public document URL' which hints at a requirement, but does not explicitly state selection criteria or prerequisites for using this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a document directly to a specific printer.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | ||
| url | Yes | ||
| media_format | Yes | ||
| device_name | Yes | ||
| control_sn | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds zero behavioral context. It does not disclose whether the operation is synchronous, what happens if the printer is offline, required permissions, or what the return value indicates (no output schema exists).
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 with no redundancy. However, given the high parameter complexity and lack of schema documentation, this brevity represents under-specification rather than appropriate conciseness.
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 tool with 5 undocumented required parameters, no annotations, and no output schema, the description is severely incomplete. It establishes the core action but leaves the agent without sufficient information to correctly populate parameters or handle responses.
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 across 5 required parameters, the description completely fails to compensate. Critical semantic gaps remain unresolved: the distinction between device_name and control_sn, valid media_format values, and whether url requires a specific protocol.
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 sends a document to a specific printer, distinguishing it from sibling tools that query printer details (query_printer_detail) or update settings (update_printer_*). However, it uses 'Send' rather than 'Print', which slightly weakens the specific action intent.
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 upload_file (a sibling tool) or whether the document must be pre-uploaded. There are no prerequisites, exclusions, or workflow context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query printer capabilities for a specific printer or shared device.
| Name | Required | Description | Default |
|---|---|---|---|
| printer_name | No | ||
| share_sn | No | ||
| device_type | No |
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 fails to specify what 'capabilities' are returned, error handling behavior (e.g., printer not found), or whether this operation requires specific permissions. The term 'Query' implies read-only, but explicit confirmation is absent.
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 single-sentence description is efficiently structured and front-loaded with the action and target. However, extreme brevity becomes a liability given the lack of schema documentation and annotations, leaving critical information unstated.
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?
Inadequate for the tool's complexity. With three optional parameters (suggesting multiple query patterns), zero schema descriptions, no output schema, and no annotations, the description should explain parameter relationships, return value structure, and lookup precedence. It provides none of these.
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?
Given 0% schema description coverage, the description must compensate but only partially succeeds. It mentions 'specific printer or shared device' implying 'printer_name' and 'share_sn', but does not explain the distinction between them, valid values for 'device_type', or that all parameters are optional with null defaults.
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 provides a clear verb ('Query') and resource ('printer capabilities'), and distinguishes from sibling 'query_printers' by specifying 'for a specific printer'. However, it could better differentiate from the 'update_printer_*' siblings by explicitly stating this is a read-only information retrieval operation.
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 provided on when to use this versus 'query_printers', or how to select between the identification parameters ('printer_name' vs 'share_sn'). The description does not indicate that all parameters are optional or suggest how to identify the target device.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List printers available to the current user.
| 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. It discloses user-scoping ('current user') implying authorization context, but does not describe the return format, pagination behavior, or whether the listing includes offline printers.
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 consists of a single, efficient sentence with no extraneous words. It is appropriately front-loaded with the core action and subject.
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 that this is a simple zero-parameter listing tool without an output schema, the description is minimally complete. It could be improved by mentioning that it returns a collection/list of printer objects, but the current description is sufficient for invocation.
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 zero parameters. Per the scoring rules, zero parameters establishes a baseline score of 4. The description appropriately reflects that no filtering parameters are required.
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 provides a clear verb ('List') and resource ('printers') with scope ('available to the current user'). However, it does not explicitly differentiate from the sibling 'query_printer_detail' (which likely retrieves specific printer information) in the text itself.
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 siblings like 'query_printer_detail', 'direct_print_document', or the various update_printer_* tools. It does not state prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update color mode for an existing roaming task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| color | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates mutation via 'Update' and specifies the roaming task context, but fails to disclose valid color values (string|null is ambiguous), error behavior for missing tasks, or whether updates are immediate.
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 single sentence is front-loaded and contains no redundant words. However, it is arguably too concise given the lack of schema coverage and annotations, leaving necessary context undocumented.
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 mutation tool with 2 parameters and 0% schema coverage, the description is insufficient. It fails to specify valid color input values, explain the null default behavior, or describe what confirms a successful update (no output schema exists to compensate).
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 partially compensates by identifying 'color' as a 'mode' and 'task_id' as referring to an 'existing roaming task'. However, it omits valid color enumerations or formats (e.g., 'color' vs 'monochrome'), which is critical given the lack of schema documentation.
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 (Update) and resource (color mode for an existing roaming task). It distinguishes from siblings like update_printer_copies by specifying 'roaming task' rather than printer hardware, and links to create_roaming_task.
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?
While 'existing roaming task' implies a prerequisite (likely created via create_roaming_task), there is no explicit when-to-use guidance or differentiation from other update_printer_* siblings. No mention of what constitutes valid color values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update copy count for an existing roaming task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| copies | Yes |
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 mutation action but fails to disclose idempotency, error conditions, side effects on the print job state, or whether this triggers immediate reprocessing.
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 single sentence contains no redundant words and front-loads the action, though its extreme brevity contributes to informational gaps given the lack of supporting schema descriptions and annotations.
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 zero schema descriptions, no annotations, and no output schema, the description is insufficiently complete. It omits behavioral implications of changing copy counts mid-process and lacks parameter specifications necessary for correct invocation.
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 compensate for both parameters. It maps 'copy count' to the 'copies' parameter and implies 'task_id' via 'existing roaming task', but provides no format constraints, valid ranges (e.g., max copies), or whether task_id is a UUID or integer.
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 provides a specific verb ('Update') and resource ('copy count') and scopes it to 'existing roaming task', clearly distinguishing it from sibling tools like update_printer_color or update_printer_paper which handle different attributes.
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?
Mentioning 'existing roaming task' implicitly signals that the task must already exist (suggesting create_roaming_task is a prerequisite), but lacks explicit guidance on when to use this versus direct_print_document or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update paper size for an existing roaming task using a preset name or custom dimensions in millimeters.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| paper | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully explains the polymorphic input behavior (preset name string vs. custom dimensions object), but fails to mention mutation effects, return values, error conditions, or whether changes are immediate or queued.
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 single sentence is tightly constructed with zero redundancy: 'Update paper size' (action), 'for an existing roaming task' (scope), and 'using a preset name or custom dimensions in millimeters' (parameter semantics). 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?
For a simple two-parameter update tool with no output schema, the description adequately covers the core functionality and input formats. However, it should ideally mention what constitutes a successful response or common error conditions (e.g., invalid task_id or unsupported preset names) to be 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?
Given 0% schema description coverage, the description compensates effectively by explaining that 'paper' accepts either a preset name (string) or custom dimensions in millimeters (object), clarifying the anyOf schema structure. It implies task_id references an existing roaming task, though explicit parameter naming would strengthen this further.
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 specific action ('Update paper size'), the target resource ('existing roaming task'), and distinguishes itself from sibling tools like update_printer_color or update_printer_copies by specifying 'paper size' as the particular attribute being modified.
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 'existing roaming task' implies this tool is for modifying previously created tasks (likely via create_roaming_task), providing implicit workflow context. However, it lacks explicit guidance on when to use this versus direct_print_document or prerequisites for the roaming task state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update simplex or duplex settings for an existing roaming task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| side | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden but provides minimal behavioral context. It doesn't specify valid values for the side parameter (e.g., 'simplex' vs 'duplex'), explain the default null behavior, indicate idempotency, or mention permission requirements for modifying tasks.
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 of 9 words with zero redundancy. The information is front-loaded with the action verb 'Update'. However, given the 0% schema coverage and lack of annotations, the brevity contributes to under-documentation rather than efficient communication.
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 2-parameter mutation tool with no output schema and no annotations, the description is insufficient. It omits critical details like valid enum values for 'side', the effect of null, error conditions, or whether the update is persistent or immediate.
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%, requiring the description to compensate. While 'simplex or duplex' hints at valid values for the 'side' parameter, it doesn't confirm exact string values, explain the null default, or describe what 'task_id' represents (format/source). Insufficient compensation for complete lack of schema documentation.
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 updates 'simplex or duplex settings' (specific resource) for an 'existing roaming task' (scope). It effectively distinguishes from sibling update_printer_* tools (color, copies, paper) by specifying the duplex/simplex domain, though it assumes familiarity with 'roaming task' from create_roaming_task.
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 mention of 'existing roaming task' implies a prerequisite (task must exist first), suggesting usage order. However, it lacks explicit guidance on when to use this versus direct_print_document or other update tools, and doesn't clarify that null side might reset to default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local file and return a public URL that the print service can read.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool returns a 'public URL' (important security context) and implies a side effect (upload). However, it omits critical mutation details: URL persistence, file cleanup policies, size limits, or authentication requirements.
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 13-word sentence with zero waste. It front-loads the action ('Upload'), specifies the input ('local file'), output ('public URL'), and domain context ('print service') with no redundant phrases.
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 single-parameter tool without output schema or annotations, the description adequately covers the basic contract (input file → output URL). However, it leaves operational gaps regarding the 'public URL' security implications, longevity, and whether the upload is temporary or persistent.
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 0% (file_path has no description). The text adds minimal semantic value by implying file_path is a local filesystem path ('local file'), but fails to specify format constraints, absolute vs. relative paths, or supported file types needed to fully compensate for the schema gap.
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 specific verb 'Upload' with clear resource 'local file' and distinguishes itself from printer-management siblings by specifying the outcome is 'a public URL that the print service can read.' This clearly positions it as a file preparation step for printing.
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 implied usage context by mentioning 'print service can read,' suggesting when to use it (when files need to be made accessible for printing). However, it lacks explicit when-to-use guidance versus direct_print_document or prerequisites.
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.
v0.1.2check_install_progresscreate_roaming_taskdirect_print_documentquery_printer_detailquery_printersupdate_printer_colorupdate_printer_copiesupdate_printer_paperupdate_printer_sideupload_fileThe four update_printer_* tools are named as if they configure printer hardware settings, but they actually modify roaming task parameters. This creates dangerous ambiguity with query_printer_detail (which queries actual printer capabilities), forcing agents to rely entirely on descriptions to distinguish printer properties from job configuration.
While most tools follow verb_noun patterns (create_roaming_task, upload_file), direct_print_document breaks convention by using an adjective-noun structure. More critically, the update_printer_* prefix is domain-inaccurate since these modify tasks, not printers, creating inconsistency with the actual object model.
Ten tools is a reasonable count for cloud printing functionality, covering environment checks, printer discovery, file handling, and dual print workflows. However, the granularity of four separate single-property update tools feels slightly excessive compared to a unified task update operation.
Basic printing and discovery are covered, but the roaming task workflow lacks lifecycle management: you can create and modify tasks, but cannot submit, check status, cancel, or list jobs. This leaves agents unable to track print completion or handle failures in the roaming workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud printing integration for AI-assisted app development via ezeep.
Print and mail physical documents in the US via USPS, with quotes, agent payment and tracking.
Print & mail PDF/HTML/Markdown/text/DOCX/images to US addresses; pay per call in x402 USDC on Base.
Cloud PDF generation from HTML, CSS and XSL-FO, with PDF/A and PDF/UA support.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zimsoft/webprinter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
