dexe-mcp

Upload raw bytes (avatar, attachment, etc.) to IPFS (Pinata)

dexe_ipfs_upload_file

Pins a local file or base64 content to IPFS and returns its CID v1 and filename; use filePath for files up to 25 MB.

Instructions

Writes to a remote service. Pins a file to IPFS; PREFER filePath over base64. Returns CID v1 (base32) + filename. Images are magic-byte gated to rasters and renamed .jpeg unless normalizeImageExt: false.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "dexe_ipfs_upload_file"
  }
}

Input Schema

Name	Required	Description	Default
`base64`	No	Base64 file bytes — only when the content isn't a local file.
`fileName`	No	Filename to pin it under, with extension.	file
`filePath`	No	Absolute path to a local file, max 25 MB — the server reads it. Preferred over base64.
`contentType`	No	MIME type of the bytes.	application/octet-stream
`normalizeImageExt`	No	If contentType starts with image/, rename the extension to .jpeg.

Output Schema

Name	Required	Description
`cid`	Yes	CID v1 base32 — use this as avatarCID.
`size`	Yes
`cidV0`	Yes	Original CID returned by Pinata (usually v0 Qm...). Kept for legacy callers.
`fileName`	Yes	Filename actually pinned (possibly normalized to .jpeg).
`pinnedAt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.37.1Nov 11, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds real value by flagging that data is written to a remote service, that images are magic-byte gated to rasters, and that extensions are rewritten to .jpeg unless normalizeImageExt is false. That describes an observable mutation of user input (filename) that an agent would otherwise not expect. It still omits whether pins are public/immutable and any auth requirements.

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?

Four short, front-loaded clauses with no filler, and the preference tip and return value appear before the edge-case renaming rule. The opening ''Writes to a remote service'' is generic but earns its place as a side-effect warning.

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?

With full schema coverage and an output schema, the description need not explain parameters or return values in depth, and it covers the non-obvious behavioral quirks. The remaining gap is sibling differentiation and permission/auth context for a tool that writes to an external service.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all five parameters; the baseline is 3. The description adds cross-parameter meaning by tying `normalizeImageExt` to the image/contentType renaming behavior and reinforces the filePath-over-base64 preference, but adds no new format or size detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (''Pins a file to IPFS'') plus the return shape (CID v1 base32 + filename), so an agent knows exactly what the tool produces. It does not distinguish itself from close siblings like dexe_ipfs_upload_avatar or dexe_ipfs_upload_proposal_metadata, leaving that routing to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Implied usage: it is the raw-bytes path and the description says to PREFER `filePath` over base64, which is parameter-level guidance. There is no explicit when-to-use versus the specialized avatar/proposal-metadata uploaders, and no stated prerequisites or exclusions.

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

Deploy Server