Skip to main content
Glama

printing-labs

by com.printinglabs

create-onboarding-drop

HR/HRIS automation (requires an API key in the Authorization header — Bearer plk_…): turn new hires into welcome-kit claim links in one call. Creates a Swag Drop for the chosen kit, invites each employee by email, and returns the claim + HR dashboard links. Each employee picks their own size and delivery address; Printing Labs prints, packs and ships per recipient.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companyNoCompany name shown on the claim page (defaults to the API-key label)
messageNoWelcome message shown to employees on the claim page
employeeNamesNoOptional names, parallel to employeeEmails
employeeEmailsYesNew-hire email addresses (1–50); each receives a claim-link email
kitProductSlugYesThe product or preset-bundle slug to send (from search-products)
notifyEmployeesNoEmail each employee their claim link immediately (default true)

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosure. It mentions the API key requirement, the creation side effects (email invites), the return values (claim + HR dashboard links), and the fulfillment flow. It omits details on reversibility or idempotency, but primary behaviors are transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two dense sentences, front-loaded with purpose and auth, and conveys all necessary high-level information without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers the purpose, authentication, flow, and return values. It could mention edge cases or failure modes, but for a creation tool with a clear goal, it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptive property definitions, so the baseline is 3. The description adds minimal extra meaning beyond the schema (e.g., 'chosen kit' maps to kitProductSlug). No compensation needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb+resource: 'Creates a Swag Drop for the chosen kit, invites each employee by email, and returns the claim + HR dashboard links.' This uniquely identifies the tool's function and distinguishes it from siblings like request-quote or track-order.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for use: 'turn new hires into welcome-kit claim links in one call' and 'HR/HRIS automation.' It doesn't explicitly mention alternatives or exclusions, but the context is strong enough to infer when this tool is applicable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All printing-labs toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct action or resource: product discovery vs pricing vs orders vs meetings vs support. While get-company-info, get-site-info, and get-guide all provide reference material, their scopes are clearly separated (verified facts vs FAQ/how-it-works vs published articles). No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: book-, cancel-, reschedule-, get-, search-, list-, request-, track-, reorder-, create-. Even exceptions like my-orders and my-invoices fit a possessive pattern that is predictable. No mixed conventions or vague verbs.

Tool Count4/5

24 tools is on the high end but appropriate for the breadth of this server's scope: product catalog, pricing, meetings, orders, invoices, support, guides, company info, and SEO. Each tool fills a specific niche, and none feel redundant. It is slightly heavy but not overwhelming for the domain.

Completeness4/5

The tool surface covers the core workflows well: product search/details/pricing, meeting booking/cancel/reschedule, order viewing/tracking/reordering, quotes, complaints, callbacks, invoices, guides, and company information. A minor gap is the absence of a direct 'place new order' tool, but request-quote and reorder handle the necessary paths, and other interactions (e.g., complains) have clear entry points.

Resources