PeerPush

Create a Product

peerpush_create_product

Create a private, unclaimed product on PeerPush. No API key or account is needed to create. Accepts the same fields as POST /api/v1/products and returns the same data envelope: id, status, claimUrl, expiresAt, claimedAt. Show the private claim link to the user so they can sign in, confirm details in the normal editor, and choose a plan. This does not claim, publish, or purchase anything. Keep the claim link private. Only create when the user asks to create a product. Each successful call creates a new product; do not automatically retry after an uncertain response.

Input Schema

TableJSON Schema

Name	Required	Description
`mrr`	No
`name`	Yes
`logoUrl`	Yes
`tagline`	Yes
`useCases`	No
`audiences`	No
`platforms`	No
`apiDocsUrl`	No
`categories`	No
`externalId`	No
`websiteUrl`	Yes
`appStoreUrl`	No
`description`	Yes
`linkedinUrl`	No
`pricingType`	No
`alternatives`	No
`contactEmail`	Yes	Contact address for the person who should claim this product. Required. Never published or returned by the API, and only PeerPush staff can see it. PeerPush emails it once, to remind the owner to claim the product before the link expires.
`mcpServerUrl`	No
`playStoreUrl`	No
`discountCodes`	No
`startingPrice`	No
`screenshotUrls`	No
`twitterUsername`	No
`cliInstallCommand`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 22, 2026

changedInput schema / properties / contactEmail / description

Previous value: -"Contact address for the person who should claim this product. Required. Never published or returned by the API, and PeerPush sends no mail to it; only PeerPush staff can see it."New value: +"Contact address for the person who should claim this product. Required. Never published or returned by the API, and only PeerPush staff can see it. PeerPush emails it once, to remind the owner to claim the product before the link expires."

Changed1 schema field changedSep 21, 2026

changedInput schema / properties / contactEmail / description

Previous value: -"Required contact address for whoever should receive the claim link. Never published; only PeerPush staff can see it."New value: +"Contact address for the person who should claim this product. Required. Never published or returned by the API, and PeerPush sends no mail to it; only PeerPush staff can see it."

Changed7 schema fields changedSep 21, 2026

removedInput schema / properties / contactEmail / anyOf

Removed value: -[
-  {
-    "format": "email",
-    "maxLength": 320,
-    "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / contactEmail / description

Previous value: -"Optional contact address for whoever should receive the claim link. Never published; only PeerPush staff can see it."New value: +"Required contact address for whoever should receive the claim link. Never published; only PeerPush staff can see it."

addedInput schema / properties / contactEmail / format
```
Added value: +"email"
```
addedInput schema / properties / contactEmail / maxLength
```
Added value: +320
```

addedInput schema / properties / contactEmail / pattern

Added value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

addedInput schema / properties / contactEmail / type
```
Added value: +"string"
```

changedInput schema / required

Previous value: -[
-  "name",
-  "tagline",
-  "description",
-  "websiteUrl",
-  "logoUrl"
-]New value: +[
+  "name",
+  "tagline",
+  "description",
+  "websiteUrl",
+  "logoUrl",
+  "contactEmail"
+]

Changed1 schema field changedSep 21, 2026

addedInput schema / properties / contactEmail

Added value: +{
+  "anyOf": [
+    {
+      "format": "email",
+      "maxLength": 320,
+      "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Optional contact address for whoever should receive the claim link. Never published; only PeerPush staff can see it."
+}

AddedSep 15, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, it discloses the no-auth requirement, non-idempotent behavior ('Each successful call creates a new product'), the no-retry caution after uncertain responses, privacy instruction for the claim link, and the fact that nothing is claimed/published/purchased. This is substantial behavioral context.

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 compact, front-loaded with the core purpose, and every sentence adds necessary operational information: auth, endpoint parity, return value, user interaction, exclusions, and retry guidance. There is no filler.

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?

The definition is unusually complete for a mutation: it covers auth, side effects, output envelope, user-handling steps, and failure/retry guidance. It falls slightly short only in not compensating for the minimal schema coverage of the many input fields, though the endpoint-parity reference partially mitigates that.

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

Parameters2/5

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

Schema coverage is only 4%, so the description bears a heavy responsibility to explain 24 parameters, but it only refers generically to 'the same fields as POST /api/v1/products' without explaining any parameter semantics. The output fields are listed, but no meaning is added for inputs like mrr, alternatives, discountCodes, or how to populate required fields.

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 opens with a specific verb and resource—'Create a private, unclaimed product on PeerPush'—and clarifies the object's state (private, unclaimed). It also distinguishes itself by describing the return envelope with claimUrl, which none of the read/discovery sibling tools would produce.

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?

It explicitly states the trigger condition: 'Only create when the user asks to create a product.' It also gives when-not context by noting the tool 'does not claim, publish, or purchase anything,' but it does not name sibling alternatives or describe when a discovery tool should be used instead.

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

All PeerPush 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?