Pinata
Manage public IPFS files and groups, inspect gateways and upload metadata, and create constrained signed upload URLs through Pinata's V3 APIs.
Verdict
Common use cases
- Pin design assets to IPFS for decentralized hosting
- Audit uploaded files across public gateways
- Organize content into groups before sharing CIDs
- Generate signed upload URLs for client submissions
- Verify file availability and retrieve content identifiers
Integration
- Vendor
- Pinata
- Category
- other
- Auth
- API_KEY
- Tools
- 9
- Composio slug
pinata
Tools
- Create Public Group
Create a group for organizing files on the connected account's public IPFS network. The connected Pinata JWT must include org:groups:write.
- Create Signed Public Upload URL
Create a 60-second signed URL for one size- and MIME-constrained public IPFS upload. The URL is a secret: use it immediately and never log or persist it. This action does not upload content itself. The connected Pinata JWT must include org:
- Delete Public Groupdestructive
Permanently delete one public-network group by ID. This destructive action does not delete the files the group organized. The connected Pinata JWT must include org:groups:write.
- Get Public Group
Return one public-network group by its Pinata group ID. The connected Pinata JWT must include org:groups:read.
- List Gateways
Return one page of gateways owned by the connected Pinata account without changing gateway configuration. The connected Pinata JWT must include org:gateways:read.
- List Public Files
Return one page of files on the connected account's public IPFS network, optionally filtered by file attributes. The connected Pinata JWT must include org:files:read.
- List Public Groups
Return one page of groups that organize files on the connected account's public IPFS network. The connected Pinata JWT must include org:groups:read.
- List Upload Metadata
List upload-service records, including upload IDs, filenames, CIDs, sizes, group IDs, and timestamps. Use List Public Files instead to search the public IPFS file inventory.
- Update Public Group
Update the name, visibility flag, or both for one public-network group. The connected Pinata JWT must include org:groups:write.
Setup
Setup guide
- 11. Log into your Pinata account and navigate to API Keys in the developer settings. 2. Generate a new JWT with scopes for the tools you need: org:files:read for listing files, org:groups:write for creating groups, org:gateways:read for gateway access. 3. Copy the JWT immediately — Pinata shows it once. 4. In Switchy, open your workspace settings and click Integrations, then Add MCP. 5. Select Pinata from the list and paste your JWT into the API Key field. 6. Click Connect and wait for the green confirmation. 7. Open any Project and type '@Pinata list my public files' to verify the connection works. 8. If you see a permissions error, regenerate your JWT with the missing scope and reconnect.
What teammates see: by default, memories from Pinata are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
List Recent Uploads
@Pinata show me the 20 most recent files uploaded to my public IPFS network, including their CIDs and upload dates.
Create Asset Group
@Pinata create a new group called 'Q1 Marketing Assets' for organizing files on my public network.
Generate Upload URL
@Pinata create a signed upload URL that accepts PNG files up to 5MB and expires in 60 seconds.
Check Gateway Status
@Pinata list all gateways on my account and show me their domain names and status.
Find Group Contents
@Pinata get the details for group ID 12345, including the files it contains and when it was last updated.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@pinata list all files in my public IPFS storage that were uploaded in the last 7 days, grouped by MIME type
Based on the List Public Files tool, here's an illustrative summary of recent uploads: **Images (image/png, image/jpeg):** 14 files, totaling 8.2 MB. Largest: banner-2024.png (2.1 MB, CID: Qm...abc). **Documents (application/pdf):** 3 files, totaling 1.4 MB. Most recent: whitepaper-draft.pdf uploaded 2 days ago. **Video (video/mp4):** 1 file, 45 MB, uploaded 5 days ago. All files are accessible via your configured gateway. This represents one page of results; pagination may be needed for accounts with high upload volume.
This example demonstrates read-only inventory access. The connected API key must include org:files:read scope. Pinata's List Public Files tool returns paginated results (typically 10-100 items per page), so large file collections require multiple queries. MIME type grouping happens in the AI layer, not the MCP itself.
@pinata create a new group called 'Q1-Marketing-Assets' and generate a signed upload URL for adding a 5MB PNG file to it
Illustrative workflow: **Step 1 — Group created:** Group 'Q1-Marketing-Assets' now exists with ID grp_abc123. You can assign files to this group for organizational purposes. **Step 2 — Signed URL generated:** A 60-second upload URL has been created, constrained to image/png files up to 5 MB. This URL is a secret credential — use it immediately in your upload client and do not log or store it. The URL expires at 14:32:15 UTC. Note: Creating the URL does not upload content. You must POST your file to the URL within 60 seconds using a separate HTTP client.
This example chains two write operations. The API key must include both org:groups:write and org:files:write scopes. The signed URL is time-sensitive and single-use — treat it like a password. Pinata does not store the file until you complete the upload via the URL. Groups are organizational containers; deleting a group does not delete its files.
@pinata show me all my configured gateways and recommend which one to use for a high-traffic NFT marketplace based on their domain names and settings
Illustrative gateway inventory: **Gateway 1:** nft-cdn.example.com — Custom domain, configured for public access. Recommended for your marketplace use case due to the branded domain and lack of rate-limiting flags in the metadata. **Gateway 2:** dev-testing.mypinata.cloud — Pinata subdomain, appears to be a development gateway based on naming convention. Not recommended for production traffic. **Gateway 3:** backup-gateway.example.io — Custom domain, metadata suggests restricted access settings. Recommendation: Use nft-cdn.example.com for marketplace traffic. Verify CORS and caching policies separately, as the List Gateways tool returns configuration metadata but not runtime performance metrics.
This example pairs MCP data retrieval with AI reasoning. The org:gateways:read scope is required. The List Gateways tool returns configuration details (domains, IDs, access settings) but not real-time analytics like bandwidth usage or error rates. Gateway selection for production workloads should also consider external monitoring data beyond what this MCP provides.
Use-case deep-dives
When Pinata makes sense for immutable game asset storage
A 6-person indie studio shipping an on-chain game needs permanent, censorship-resistant hosting for character metadata and art files. Pinata's public IPFS network is the right call here: create a group per character collection, upload assets via signed URLs, then reference the CIDs in your smart contracts. The API key auth is simple enough for a single backend service to manage. The threshold: if you're shipping more than 10,000 assets in the first month, you'll hit rate limits on the signed URL creation—budget time to batch uploads or contact Pinata for higher tiers. If your metadata changes post-mint (dynamic NFTs), IPFS immutability becomes a liability; you'd need a mutable pointer layer on top. For static game assets that must survive platform shutdowns, this MCP delivers the decentralized guarantee your community expects.
Why Pinata wins for tamper-proof contract storage
A 12-person fintech startup needs to prove document integrity for auditors without paying enterprise document-management fees. Pinata's IPFS pinning gives you cryptographic proof: upload executed contracts via the signed URL tool, organize by quarter using groups, then store the CID in your database alongside the contract record. When an auditor asks for the March 2024 NDA, you hand them the CID and they verify the hash independently. The List Public Files tool lets your compliance lead pull reports without engineering help. The catch: if you're uploading more than 500 documents a month, the 60-second signed URL expiry gets annoying—you'll want a small service that requests URLs just-in-time. If your documents contain PII that must be deleted on request (GDPR), IPFS permanence is a dealbreaker; use S3 with versioning instead. For append-only audit trails, Pinata's immutability is the feature.
When Pinata beats cloud storage for public data releases
A 4-person research collective publishes climate datasets quarterly and wants to guarantee long-term availability without cloud bills scaling with downloads. Pinata's public IPFS network is ideal: upload the dataset via signed URL, create a group for the release version, then share the gateway URL in your paper. Researchers worldwide can fetch the data from any IPFS node, not just your gateway, so a traffic spike doesn't take you offline or cost you money. The List Gateways tool lets you monitor access patterns without per-request logging. The boundary: if your dataset is under 5GB and changes frequently (weekly updates), IPFS's immutability means you're creating new CIDs constantly—consider a mutable naming layer like IPNS or just use Cloudflare R2. If your data is over 50GB, upload time through signed URLs gets painful; you'd want Pinata's bulk-upload API. For versioned, cite-able datasets that must outlive your funding, this MCP is the right infrastructure.
Frequently asked
What does the Pinata MCP do in Switchy?
It lets your team upload files to IPFS through Pinata, organize them into groups, and retrieve gateway URLs—all from the Switchy workspace. You can list existing files, create signed upload URLs, and manage groups without leaving the conversation. The MCP wraps Pinata's public IPFS network and gateway APIs, so you're working with the same content identifiers and groups you'd see in the Pinata dashboard.
Which Pinata JWT scopes does the MCP need?
You'll need org:files:read to list files, org:groups:read and org:groups:write to manage groups, and org:gateways:read to list gateways. If you only want read-only access—browsing files and groups without creating or deleting anything—org:files:read and org:groups:read are enough. Generate the JWT in your Pinata account settings and paste it into Switchy's connection flow.
Can the Pinata MCP pin files from an external URL?
No. The MCP creates signed upload URLs for direct uploads and lists files already on your account, but it doesn't pin content from arbitrary HTTP sources. If you need to pin by URL or CID, use Pinata's pin-by-CID API directly or upload the file through the signed URL flow first.
How is this different from uploading to Pinata manually?
The MCP brings Pinata into your team's AI workflow. Instead of switching to the Pinata dashboard to check if a file exists or create a group, you ask Switchy and it happens inline. The trade-off is you're limited to the nine tools the MCP exposes—advanced features like custom metadata schemas or submarine keys still require the Pinata UI or direct API calls.
Who on the team should connect the Pinata account?
Whoever owns the Pinata account or has permission to generate JWTs with the required scopes. Once connected in Switchy, any team member can trigger the MCP's tools in shared conversations. If you want to restrict who can delete groups or create upload URLs, generate a JWT with narrower scopes and connect that instead.