Skip to main content
Glama
entire-vc

EVC Mesh MCP Server

by entire-vc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

upload_artifact

Attach files, code, logs, or images to an EVC Mesh task; supports text/base64 content, metadata, and optional SHA-256 integrity checks.

Instructions

Upload an artifact (file, code, log, etc.) to a task. Downloading an artifact is two GETs. Step 1: GET /api/v1/artifacts//download with header X-Agent-Key: -> 200 JSON {"url": ""}. Step 2: GET that url with NO headers -> 200, the file bytes. Pitfalls: on step 1 only X-Agent-Key is accepted (X-API-Key and Authorization: Bearer give 401); on step 2 any extra header, Authorization in particular, breaks the presigned signature (400). The artifact's download_path is step 1's path. Never fetch browser_only_url with an agent key: it is a human page and answers 401 by design. Inline content travels through the model context, so for a binary larger than a few KB prefer the REST endpoint instead: POST /api/v1/tasks/<task_id>/artifacts as multipart/form-data with -H 'X-Agent-Key: $MESH_AGENT_KEY' -F 'name=' -F 'artifact_type=image' -F 'file=@;type=image/png' — the bytes then never enter the context and cannot be truncated on the way.

Input Schema

NameRequiredDescriptionDefault
nameYesArtifact filename.
sha256NoOptional hex sha256 of the DECODED bytes. Verified before upload; a mismatch fails the call. Recommended for binary, since it is the only check that catches a payload truncated in transit.
contentYesArtifact content. Plain text by default; set encoding="base64" to send binary.
task_idYesTask ID.
encodingNoHow to interpret content: "text" (stored as-is) or "base64" (decoded before storing). Required for binary — without it a base64 string is stored literally as the file body.text
metadataNoAdditional metadata, stored on the artifact as JSON.
mime_typeNoMIME type. Auto-detected from name if omitted. For png/jpeg/gif/pdf/zip the content is checked against the type's magic bytes and the upload is refused on a mismatch.
artifact_typeNoType: file, code, log, report, link, image, data.file

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses real behaviors: sha256 is verified before upload and a mismatch fails the call, mime magic bytes are checked and mismatched png/jpeg/gif/pdf/zip uploads are refused, and base64 content sent without encoding is stored literally. These are non-obvious traits an agent needs, though the download-header pitfalls are irrelevant to this operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The upload purpose is correctly front-loaded in sentence one, but the description then devotes most of its length to two-GET download steps, header signature pitfalls, and browser_only_url warnings — content that belongs to get_artifact and dilutes the value. For an upload tool this is poorly scoped and oversized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation tool with no output schema and full schema coverage, the description covers the important traps (sha256 verification, magic-byte refusal, truncation risk, REST fallback). It omits what the call returns and never routes to the correct sibling tools, while spending space on unrelated download mechanics.

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 description coverage is 100%, so the schema already documents name, content, encoding, mime_type, sha256 and metadata thoroughly. The description adds only marginal parameter context (implicitly warns about truncation and the encoding trap), which the schema itself already covers, so baseline 3 applies.

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?

The opening sentence gives a specific verb (upload), resource (artifact), and examples (file, code, log), so the core purpose is unmistakable. However, the bulk of the text describes a download flow that belongs to the sibling get_artifact, and no sibling is named, so it does not cleanly differentiate itself from the read-side tools.

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?

It offers one concrete routing rule — for binaries larger than a few KB prefer the REST multipart endpoint instead of inline content — which is genuine guidance. But it never states when to use this tool versus get_artifact/list_artifacts, and the download pitfalls it spends most of its length on are usage guidance for a different tool.

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

Deploy Server

Other Tools