4OVER4

Build a 4OVER4 marketing kit

marketing_kit

Read-onlyIdempotent

Builds a 4OVER4 print kit for a campaign or launch, one real product per piece (business cards, flyers, banners, signs, stickers); use it when someone plans a promotion or an opening and wants several printed pieces. For one product use show_products. Requires the goal; productTypes names the exact pieces. Returns one product per piece with slug and reason, plus a short plan. Customer phrases: "grand opening kit", "business cards, postcards and flyers for my real estate business".

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": {
      "goal": "<goal>"
    },
    "name": "marketing_kit"
  }
}

Input Schema

Name	Required	Description
`goal`	Yes	The goal or occasion, e.g. grand opening; for a set of product types, what ties them together.
`budget`	No	Approximate budget in USD.
`audience`	No	Who the campaign should reach.
`channels`	No	Where people see it, e.g. direct mail, event booth.
`industry`	No	The customer's business, e.g. cafe.
`timeline`	No	When it happens, e.g. in 3 weeks.
`productTypes`	No	Product types to include, one product each, e.g. ["business cards", "postcards", "flyers"].

Output Schema

Name	Required	Description
`data`	No	One real product per print piece for a goal, with a short plan.
`link`	No	The page on www.4over4.com to continue on: order, upload and checkout happen there.
`summary`	Yes	The facts of the result in plain sentences.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context by stating that each piece maps to one real product and that the response includes a slug, a reason, and a short plan. It stops short of describing limits such as how productTypes selections are reconciled when more than one candidate exists.

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?

Front-loaded with the action and scope, then the usage rule, then the return contract. The sample customer phrases at the end are useful for matching but push the length slightly beyond the minimum needed.

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?

Output schema exists and annotations cover safety, so the description only needs to convey purpose, routing, and the product-per-piece contract, all of which are present. Nothing an agent needs in order to call it correctly is 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, but the description adds meaning: 'goal' is required and 'productTypes' names the exact pieces while every other field (budget, audience, channels) is left to the schema. It clarifies the cardinality rule ('one real product per piece') that the array schema alone does not convey.

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 ('Builds a 4OVER4 print kit'), the scope ('one real product per piece'), and enumerates the concrete piece types. It also explicitly distinguishes itself from show_products, so an agent can route 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 Guidelines5/5

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

Gives an explicit when-to-use condition ('when someone plans a promotion or an opening and wants several printed pieces') and names the alternative for the single-product case ('For one product use show_products'). Nothing is left to inference.

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

All 4OVER4 tools Inspect

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

Need Help?