Skip to main content
Glama

Start your own shop

start_own_shop
Read-onlyIdempotent

Explains the Softwear Prints online shop plans (free, Professional, Enterprise) with prices and returns a link to set up an own shop on softwear-prints.com (staff shop, club or team shop, school, merchandise or event shop), prefilled with the organisation name and type. The user completes the setup and the account on the website; this tool sends nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "start_own_shop"
  }
}

Input Schema

NameRequiredDescriptionDefault
planNoPlan to preselect. Without it the setup starts with the free plan; the user can change it there.
billingNoBilling period to preselect for paid plans.
organisationNoName of the shop or organisation, used to prefill the shop name. Optional.
organisation_typeNoKind of organisation, used to prefill the setup: company, staff_shop, club, fire_brigade, school, university, public_authority, brand, artist, merchandise or region_tourism. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive behaviour, and the description reinforces this with the useful line that the tool sends nothing and the user finishes on the website. It also discloses the return (a setup link, prefilled) beyond what the annotations say.

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

Conciseness4/5

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

One substantive sentence followed by a short clarification, with the key output (setup link) front-loaded. Slightly dense parenthetical listing of shop types, but nothing wasteful.

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?

With no output schema, the description covers the return value (a prefilled setup link), the user handoff, and the side-effect profile. An agent has everything needed to call it and set expectations.

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%, but the description still adds meaning: it says the preselected plan defaults to free and can be changed, and that organisation/organisation_type prefill the shop name and setup. It also hints that only paid plans use billing, a nuance worth having.

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?

States a specific verb and resource: explains the shop plans (free, Professional, Enterprise) with prices and returns a prefilled setup link. This is clearly distinct from the sibling product/category tools, which an agent can see without opening the 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?

Implies the trigger well (user wants their own shop) and clarifies the division of labour: the user completes setup and account on the website. No explicit exclusions or named alternatives, but the siblings cover unrelated product-search tasks, so there is little ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources