# Reported issues for printr Pod holds 20 of 31 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user. Back to [printr](/mcp/printr). ## Most discussed ### feat(mcp): remote MCP server hosted on Cloudflare Workers ## Motivation `@printr/mcp` today is **stdio-only** — every user installs it locally via the CLI (`bunx @printr/cli setup`). That terminal-first flow is the biggest drop-off between "interested" and "agent connected" (see #113). A **remote MCP server hosted on Cloudflare Workers** gives clients a plain URL to connect to — no local install, no runtime, no keystore on the user's box. This is now unblocked: Epic A (#103) made `@printr/sdk` Workers-ready, so the core runs on a V8 isolate without v [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/124) · 2026-06-19 · open · 5 comments ### Epic A: SDK Workers-ready ## Goal `@printr/sdk` evaluates and runs cleanly on Cloudflare Workers / edge runtimes without vendoring. ## Why bundle All four sub-issues share one acceptance gate: "a Worker importing the SDK barrel evaluates without throwing." Same `package.json` `exports` surgery, same Worker eval smoke test, same release. Landing them piecemeal leaves Workers consumers half-broken between releases. ## Sub-issues - [ ] #96 — lazy-load `sharp` + `node:fs` in `image.ts` - [ ] #97 — drop `createRequire` s [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/103) · 2026-05-25 · closed · 2 comments ### feat(mcp): publish Printr skill manifest for agent composition ## Motivation Bankr publishes a [skills repo](https://github.com/BankrBot/skills) so any agent runtime can pull in their capabilities as a plug-and-play skill. We already have `packages/cli/skills/printr/SKILL.md` — this issue is about formalizing and publishing it so other agents (and our own users) can install Printr capabilities the same way. The README already advertises `npx skills add PrintrFi/printr-mcp`, but the skill itself isn't surfaced as a first-class artifact alongside the MCP se [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/64) · 2026-05-14 · closed · outside contributor · 2 comments ### docs: update gitbook for current MCP/SDK + cross-link with the dev docs ## Context While aligning the gh-pages dev docs voice to the gitbook (https://printr.gitbook.io/printr-docs/), a few gitbook pages were found **out of date** vs the current `printr-mcp` repo. Queueing a pass to fix them and to **cross-link** the gitbook (product/conceptual) with the gh-pages dev docs (https://printrfi.github.io/printr-mcp/, MCP tool + SDK reference). ## Stale items found (verify + fix) - **CLI command is wrong.** `for-agents/printr-mcp.md` + `for-agents/README.md` show `bunx [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/131) · 2026-06-20 · closed · 1 comment ### setupBareExtension: generic factory for proto/openapi wrappers ## Idea Generic factory that takes a class/ctor and returns a mapped-type object with uncapitalized method names. Collapses N near-identical wrapper modules (each generated proto/openapi service file) into one helper invocation. ```ts export function setupBareExtension any>(Ctor: T): UncapitalizeKeys> { ... } ``` ## Why - Pairs with #83 (template-literal renaming) for ergonomic proto APIs - Smaller surface in `staking-api.ts` / `fees-api.ts` once [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/84) · 2026-05-17 · closed · 1 comment ### Template-literal method renaming for proto wrappers ## Idea Strip `Request`/`Msg`/`Response` suffixes at the type level for generated proto wrappers in `fees-api.ts` and `staking-api.ts`: ```ts type SimplifyRequestMethod = T extends `${infer Base}Request` ? Uncapitalize : T; type KeepOnlySimplifiedRequestMethods = { [K in keyof T as K extends `${string}Request` ? SimplifyRequestMethod : never]: T[K]; }; ``` Lets the public surface expose `.claimRewards()` / `.createStakePosition()` etc. even when the [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/83) · 2026-05-17 · closed · 1 comment ### feat(sdk,mcp): use CAIP-10 token IDs for printr_transfer_token / executeTokenTransfer ## Context Surfaced in Copilot review on #56. The `printr_transfer_token` MCP tool and the SDK `executeTokenTransfer` dispatcher both accept an unqualified `token_address` and infer the execution chain from the recipient's CAIP-10 address. A caller who pastes a token contract from another chain (very common — many tokens deploy to multiple EVM chains under different addresses) will silently execute against whatever code or EOA happens to live at that address on the destination chain. `printr_g [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/58) · 2026-05-05 · closed · 1 comment ### Published tarball 0.16.1 ships certs/key.pem (private key) via the "files" allowlist Hello, A heads-up from outside the project rather than a bug in the code. **The published tarball for `@printr/mcp@0.16.1` contains `certs/key.pem` (227 bytes) alongside `certs/fullchain.pem` (4108 bytes).** A 227-byte PEM next to a full chain is the shape of a TLS **private** key, not a public one. It is in the current latest version, so it is in every copy installed since release; `npm pack @printr/mcp@0.16.1` reproduces it in seconds. This is not the usual packaging accident — `package.jso [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/137) · 2026-08-27 · open · external user · 0 comments ## Most recent ### feat(docs): generate SDK API reference (TSDoc → MDX, like onrails) ## Motivation #57 backfilled TSDoc across every public `@printr/sdk` export and MCP `register*Tool`. Now that the source carries structured doc comments, we can surface a proper **API reference** section in the docs site — the `sdk.mdx` page is currently a hand-written high-level map, not per-function reference. Target shape: a dedicated API section like **`~/dev/onrails`** (`apps/docs/content/docs/api/{result,maybe,pattern}.mdx`) — rich per-primitive pages with twoslash examples. ## Approach [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/125) · 2026-06-19 · open · 0 comments ### feat(sdk,cli): extract MCP client table to @printr/sdk for web reuse ## Motivation The only way to install the Printr MCP server today is the CLI (`bunx @printr/cli setup --client cursor`). This is a terminal-first flow that most app users never complete — it's the single biggest drop-off between "user is in the app" and "user has an agent connected". We want a **"Connect your agent" button** in the main app (`printr/web`) that renders the per-client MCP config (copy-to-clipboard + deep links) directly in the UI, so install moves into the product surface where [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/113) · 2026-06-02 · open · 0 comments ### Epic C: Agent trading UX ## Goal Agents using `@printr/mcp` can swap, buy, sell, and bridge — not just launch. ## Why bundle Both sub-issues: - Need the signer primitive from Epic B / #100 - Ship MCP tools + SDK adapter pair - Require provider choice + e2e fork tests - Share fee-routing / quote-flow architecture decisions Landing them as one epic forces consistent UX (quote-then-confirm vs one-shot, fee model, status polling). ## Sub-issues - [ ] #62 — trading tools: swap, buy, sell by ticker - [ ] #63 — cross-cha [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/105) · 2026-05-25 · open · 0 comments ### Epic B: Shared SDK primitives ## Goal Lift two pieces of MCP-internal logic into shared SDK subpaths so every Printr client reuses them. ## Why bundle Both extract logic currently duplicated/inlined in MCP into `@printr/sdk` subpaths. Same review pattern (subpath export, interface, two reference impls, MCP swap). #100 unblocks Epic C signing flows. ## Sub-issues - [ ] #99 — `normalizeTokenId` + token-id regex exports in `@printr/sdk/caip` - [ ] #100 — extract signer primitive to `@printr/sdk/signer` ## Order #99 first [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/104) · 2026-05-25 · open · 0 comments ### feat(sdk): processImageBytes(bytes, opts) helper ## What to build `packages/sdk/src/image.ts` exposes `processImagePath` (reads from disk via `node:fs/promises`). Add a parallel `processImageBytes(bytes: Uint8Array, opts): ResultAsync` that takes raw bytes and returns processed bytes. Use cases: - Browsers / edge runtimes / Workers — no filesystem access - HTTP servers that receive uploads in-memory (multipart, JSON-base64, etc.) - Any consumer that has already fetched the image and shouldn't have to round-trip throu [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/102) · 2026-05-25 · open · 0 comments ### feat(sdk): lighter balance via direct JSON-RPC ## What to build `packages/sdk/src/balance.ts` currently pulls `@solana/web3.js` (~600KB minified) and `viem` for balance queries. For consumers that only need to read native or SPL balances, this is a heavy tax — especially on edge/Workers runtimes with bundle size limits. Add a lighter variant that hits Solana / EVM JSON-RPC endpoints directly with `fetch` and parses responses with Zod. Same `ResultAsync` shape so the substitution is mechanical. Strategy: - Keep the [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/101) · 2026-05-25 · closed · 0 comments ### feat(sdk): extract signer primitive to @printr/sdk/signer ## What to build Lift the browser-sign-by-URL session machinery out of `packages/mcp/src/server/{sessions,app}.ts` into a new `@printr/sdk/signer` subpath. Every Printr client that needs non-custodial signing — MCP today, future apps tomorrow — wants the same primitive: mint a signing session, hand the user a URL, let them sign in their wallet, poll/await completion. This is a high-leverage upstream change: it lets a client orchestrate signing flows without ever holding a private key. Shape ( [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/100) · 2026-05-25 · open · 0 comments ### feat(sdk): normalizeTokenId + token-id regex exports ## What to build Every Printr client (MCP server, future apps) needs to accept user-typed token identifiers in any of these forms: - Telecoin ID hex (e.g. `0xda97f29a4c137298ed138194b39b8b81eb7889018cd9ae4ab4a053fe0bfb7ed5`) - EVM CAIP-10 (e.g. `eip155:8453:0x...`) - Solana CAIP-10 (e.g. `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp:G6mNZ...`) - **Bare Solana mint base58** (e.g. `G6mNZN8o16QBcTqfuEx6FzjiWa94B1XWhfyDxjDibrrr`) …then normalize to a canonical form the API accepts. The MCP and any fut [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/99) · 2026-05-25 · open · 0 comments ### feat(sdk): types-only @printr/sdk/openapi entry ## What to build Add a `./openapi` subpath export to `@printr/sdk` that re-exports **only** the generated OpenAPI types — `paths`, `components`, `operations` — from `api.gen.d.ts`. No runtime code. Today, consumers wanting strict response types have to: 1. Either import from `@printr/sdk/client`, which now pulls runtime JS (broken on Workers; see #97), or 2. Define their own loose types and lose strict generated shapes, then cast at every API call site. A types-only entry lets clients pull s [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/98) · 2026-05-25 · closed · 0 comments ### fix(sdk): emit Workers-friendly bundle, drop createRequire shim ## What to build Every module in `@printr/sdk/dist/*` currently starts with: ```js import { createRequire } from "node:module"; var __require = createRequire(import.meta.url); ``` This is Bun's bundler default for CJS interop with deps that ship CommonJS (e.g. `neverthrow`'s `.cjs.js`). Cloudflare Workers throws on evaluation because `createRequire(import.meta.url)` receives `undefined` for `import.meta.url` in some configurations and because `node:module` isn't a Workers primitive even with [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/97) · 2026-05-25 · closed · 0 comments ### fix(sdk): lazy-load sharp + node:fs in image.ts ## What to build `packages/sdk/src/image.ts` statically imports `sharp` and `node:fs/promises` at module top level. The `@printr/sdk` barrel re-exports `buildToken` from `token.ts`, which re-exports `image.ts` transitively — so importing **anything** from the SDK barrel pulls those Node-only deps into the consumer bundle. This kills the SDK in any non-Node runtime (Cloudflare Workers, browser, Deno-without-node-compat, edge functions). Move the `sharp` and `node:fs/promises` imports inside th [Read the thread](https://github.com/PrintrFi/printr-mcp/issues/96) · 2026-05-25 · closed · 0 comments ### Migrate signAndSubmit{Evm,Svm} to ResultAsync ## Context The public signers in \`packages/sdk/src/evm.ts\` and \`packages/sdk/src/svm.ts\` still return \`Promise\` and throw on every failure mode (no RPC, broadcast failure, on-chain revert, confirmation timeout). This violates the project rule "use neverthrow Result types for all failable operations" \([feedback\_neverthrow\_match\](../blob/main/AGENTS.md)\). Discovered during PR #92 audit. ## Scope **SDK (signers + helpers):** - \`signAndSubmitEvm\` → \`ResultAsync