Skip to main content
Glama
Sign In

massprint

by com.themassprint
OverviewDiscussionsAdmin

Apply for an enterprise account

apply_enterprise
Idempotent

Apply for an enterprise (invoiced) account, for platforms printing at volume behind their own checkout. Enterprise orders auto-confirm with no payment link and are settled monthly, with a minimum of ₹10,000 of orders a month (a month below that is billed at retail). Storybooks are priced 25% below the retail price list (every copy at that price), and custom-cut stickers have lower platform prices. Greeting cards are the retail price for everyone. Requires a registered India GSTIN for tax invoicing. It is checked against the GST registry, and one the registry lists as cancelled is refused. No key is issued here or sent by email. A person reviews the application, and once approved the person at contact_email signs in at https://themassprint.com/business with a one-time email code (no password) and creates the API key there, shown once. Once approved, you pay a ₹10,000 advance at themassprint.com/business before you create the API key. Online it costs ₹10,205 by UPI or netbanking, or ₹10,310 by card, wallet, EMI or Pay Later, which covers Razorpay's fee. The advance is adjusted against your first monthly bill, and you can pay it by bank transfer instead. Use this only when a human has asked to set up a business or enterprise print account.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company_name": "<company_name>",
      "contact_email": "<contact_email>",
      "gstin": "<gstin>"
    },
    "name": "apply_enterprise"
  }
}

Input Schema

NameRequiredDescriptionDefault
gstinYes15-character India GSTIN, e.g. 29ABCDE1234F1ZW. The last character is a check character. Required for GST invoicing.
notesNoAnything else for the reviewer (optional).
company_nameYesRegistered business name.
contact_emailYesThe person who will run the account. Once approved they sign in at https://themassprint.com/business with this email to create API keys. Invoices go here too.
expected_monthly_volumeNoApproximate orders a month (optional).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / contact_email / description
      Previous value: -"Where the approved API key and invoices are sent."New value: +"The person who will run the account. Once approved they sign in at https://themassprint.com/business with this email to create API keys. Invoices go here too."
    • changedInput schema / properties / gstin / description
      Previous value: -"15-character India GSTIN, e.g. 29ABCDE1234F1Z5. Required for GST invoicing."New value: +"15-character India GSTIN, e.g. 29ABCDE1234F1ZW. The last character is a check character. Required for GST invoicing."
  2. Changed1 schema field changed
    • changedInput schema / properties / expected_monthly_volume / description
      Previous value: -"Approximate books printed per month (optional)."New value: +"Approximate orders a month (optional)."
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare the mutation/idempotency profile; the description goes far beyond it, disclosing that orders auto-confirm with no payment link, settle monthly with a ₹10,000 minimum, that GSTIN is checked against the registry and cancelled registrations are refused, that no key is issued here, that a human reviews the application, and that a ₹10,000 advance is required before key creation. This is exactly the kind of precondition and downstream-state disclosure an agent needs before committing a mutation.

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

Conciseness3/5

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

The purpose and eligibility constraints are front-loaded and earn their place, but the middle section drifts into granular payment-channel pricing (₹10,205 vs ₹10,310 covering Razorpay's fee) that is not needed to decide or invoke the tool. The core message could be roughly half the length without losing decision-relevant information.

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

Completeness5/5

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

For an application-submission tool with no output schema, the description covers the full lifecycle an agent must communicate: human review, approval, sign-in via one-time email code, advance payment, and key creation. Nothing an agent or user needs to act correctly appears to be missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds meaning beyond the schema by explaining that the GSTIN is validated against the GST registry and rejected if cancelled, and that contact_email is the identity used for later sign-in and invoicing. The pricing tiers (storybooks 25% below retail, greeting cards at retail) add interpretation context for what the applicant is signing up for.

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?

Opens with a specific verb+resource (apply for an enterprise/invoiced account) and immediately scopes it to 'platforms printing at volume behind their own checkout.' This is clearly distinguishable from the sibling read/create tools (get_account, create_order, validate_pdf) without needing to open any schema.

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 final sentence gives an explicit gating condition: 'Use this only when a human has asked to set up a business or enterprise print account,' which tells the agent when to invoke versus when not to. It does not name an alternative tool for self-serve signup, but the human-trigger constraint is unusually clear for a tool of this type.

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

All massprint toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources