Skip to content

Add Printr plugin#71

Open
alanrsoares wants to merge 2 commits into
base:masterfrom
alanrsoares:feat/printr-plugin
Open

Add Printr plugin#71
alanrsoares wants to merge 2 commits into
base:masterfrom
alanrsoares:feat/printr-plugin

Conversation

@alanrsoares

Copy link
Copy Markdown

Adds a Base MCP plugin for Printr, a cross-chain token launchpad.

What it does

Lets an agent quote, build, and launch a token on Printr from chat. The plugin reads and builds an unsigned EVM transaction over Printr's public HTTP API, then submits the raw { to, value, data } calldata through Base MCP send_calls — the user signs and broadcasts via their Base Account. Covers the EVM chains Base MCP supports: base, arbitrum, optimism, polygon, bsc, avalanche, ethereum.

  • integration: http-api — Printr's API is public (no auth). Build calldata via POST /print, submit via send_calls.
  • File: skills/base-mcp/plugins/printr.md

Notes for review

  • http-api, not external-mcp. Printr ships its own MCP server, but this plugin intentionally talks to the public HTTP API directly so the write always routes through Base MCP send_calls (the smart-wallet approval gate) rather than Printr's own signer. No extra MCP install required — Base MCP only.
  • Followed the merged-plugin house style (bankr/uniswap) over the newer canonical spec headings: 2-field frontmatter, prose overview, ## API, send_calls mapping as an Orchestration subsection, Execution Warnings / Safety Notes / Notes. Conforms to tone.md (onchain, no web3).
  • API host: currently points at api-preview.printr.money. Happy to repoint at the stable production host before merge if preferred — flag it and I'll push the change.

Authored per the plugin spec and verified against the Authoring Checklist.

Match the merged-plugin house style (bankr/uniswap): 2-field frontmatter
with the 'Skill plugin reference for' description idiom, prose overview in
place of canonical spec headings, '## API' endpoints, send_calls mapping as
an Orchestration subsection, bold-prompt examples, and Execution Warnings /
Safety Notes / Notes sections. Enforce tone.md rules (onchain, no web3).
@cb-heimdall

Copy link
Copy Markdown
Collaborator

🟡 Heimdall Review Status

Requirement Status More Info
Reviews 🟡 0/1
Denominator calculation
Show calculation
1 if user is bot 0
1 if user is external 0
2 if repo is sensitive 0
From .codeflow.yml 1
Additional review requirements
Show calculation
Max 0
0
From CODEOWNERS 0
Global minimum 0
Max 1
1
1 if commit is unverified 0
Sum 1

@stephancill stephancill left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the submission. There are structural conformance gaps and the documented API does not currently function, both of which need to be resolved before this can be reviewed for merge.

Required — structure

  • The frontmatter is missing nearly all required fields: tags, name, version, integration, chains, and the capability flags. These are the routing/discovery signals surfaced in the SKILL.md table, so without them the plugin is undiscoverable. Add the full frontmatter block.
  • The required ## Surface Routing and ## Submission sections are absent. Add them.
  • Non-canonical headings: ## API, ## Execution Warnings, ## Safety Notes. Rename to ## Endpoints and fold the warnings into ## Risks & Warnings.

Required — functional

  • "All endpoints are public (no auth)" is incorrect. api.printr.money requires authentication (returns 401) and the production OpenAPI gates all endpoints behind bearerAuth. Correct the documented auth model and set auth accordingly.
  • The documented host api-preview.printr.money/v0 returns HTTP 500 on every endpoint (/print/quote, /print, /tokens/{id}), so the plugin cannot build calldata against it. Point the plugin at a working, stable production host.

Minor

  • Request schema mismatches that would fail the quote/build calls even with valid auth:
    • initial_buy is documented as a bare string ("0.1"), but the API requires an object (VariableInitialBuy) selecting one of three denomination modes: {spend_native: "<amount>"}, {spend_usd: <amount>}, or {supply_percent: <amount>}. A bare string is ambiguous (native vs USD vs percent), so the backend rejects it. Update the field type and examples, and pass whichever variant the user specifies.
    • graduation_threshold_per_chain_usd: 5000 is below the schema minimum of 15000 (max 1000000). Use an in-range value in the examples.

@youssefea

Copy link
Copy Markdown
Collaborator

Note: this is an AI-generated review. An automated, read-only API/endpoint health check — not a human review.

Thanks for the submission — appreciate the work on the Printr plugin! As part of reviewing the Wave 2 submissions I ran an automated, read-only health check against the documented endpoints. A couple of these are blocking the documented flow right now, so flagging them early so they're easy to fix:

Findings

  • Blocking — All documented endpoints on the documented base URL https://api-preview.printr.money/v0 return HTTP 500 unable to handle request on read-only calls: POST /print/quote (with the documented body and with {}), POST /print (build), GET /tokens/{id}, and GET /tokens/{id}/deployments. The route layer is alive (OPTIONS /print/quote -> 200 with Allow: GET,POST,PUT,DELETE,OPTIONS; a GET on the POST-only quote route -> 405), so the routes exist but the origin handler fails on every real request (consistent across retries). The quote -> build -> send_calls happy path cannot complete against the documented host as-is.
  • Major — Auth claim contradicted. The doc states "All endpoints are public (no auth)", but the production host https://api.printr.money/v0 returns HTTP 401 unauthorized on every endpoint (including OPTIONS). If the plugin falls back to the stable production host (the documented preview host is down), the documented no-auth flow will not work without credentials.
  • Major — The documented base URL is explicitly a preview host (api-preview.printr.money, called "the SDK default" in the doc). Preview/staging origins are commonly unstable, which matches the uniform 500s observed. Pinning the documented launch path to a preview origin is fragile.
  • Minor — The returned router address payload.to is only validated for its eip155:<chainId>: prefix before submission via send_calls; it is not checked against a documented Printr contract constant. to, calldata, and value all originate from the same partner API, so a bad response is submitted unchecked. (The smart-account signature concern does not apply: calldata/value are pass-through and no off-chain signature is baked into calldata.)
  • Note: value is documented as already-wei decimal string and passed through; if send_calls requires hex-encoded value, this would need encoding — could not confirm the live shape because the build endpoint 500s.

What was checked

Read-only probes only. DNS/TLS via dig/curl -sI for api-preview.printr.money, api.printr.money, and app.printr.money (all resolve and serve TLS over Cloudflare). curl GET/POST/OPTIONS against all four documented endpoints, with both the documented request body and an empty body, recording HTTP status and error shape (no real launch — the only mutating endpoint, POST /print, was probed with an empty body to read its error path). Unauthenticated probes of the production host to test the "no auth" claim. npm view for a Printr SDK package (@printr/sdk v0.6.1 exists; repo PrintrFi/printr-mcp). No documented on-chain contract constants exist to cast code (the contract address is returned dynamically in payload.to). This was read-only: no transactions were submitted, no funds moved, and no API keys were used.

Really appreciate the contribution — happy to clarify any of the above. Since this is an automated check, please double-check anything that looks unexpected on your end before changing it.


Generated by an AI assistant (Claude) after an automated, read-only deep analysis of the API/endpoint health documented in this plugin. It checks endpoint reachability, HTTP status codes, response shapes, auth behavior, SDK/package existence, and on-chain contract presence — it does not submit transactions or move funds. Please independently verify any finding before acting on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants