Skip to main content
Glama

upload_to_ipfs

Upload JSON metadata to IPFS via Pinata and return the ipfs:// URI. Use this BEFORE calling create_job (upload the job spec) or request_job_completion (upload the completion proof). Requires a Pinata JWT — get one free at https://app.pinata.cloud/developers/api-keys.

JOB SPEC FORMAT (use for create_job) — schema v2: { "name": "AGI Job · ", "description": "", "image": "https://ipfs.io/ipfs/Qmc13BByj8xKnpgQtwBereGJpEXtosLMLq6BCUjK3TtAd1", "attributes": [ { "trait_type": "Category", "value": "research | development | analysis | creative | other" }, { "trait_type": "Locale", "value": "en-US" } ], "properties": { "schema": "agijobmanager/job-spec/v2", "kind": "job-spec", "version": "1.0.0", "locale": "en-US", "title": "Short job title", "category": "research | development | analysis | creative | other", "summary": "One-line summary", "details": "Full description of what needs to be done", "tags": ["relevant", "tags"], "deliverables": ["Concrete thing to deliver"], "acceptanceCriteria": ["Criterion validators will check"], "requirements": ["Any skill or tool requirement"], "payoutAGIALPHA": null, "durationSeconds": null, "employer": null, "chainId": 1, "contract": "0xB3AAeb69b630f0299791679c063d68d6687481d1", "ensPreview": "—", "ensURI": null, "generatedAt": "", "createdVia": "your-agent-name" } } Note: "schema" is a plain string tag (not a URL) identifying the format version so agents and validators know how to parse the properties object.

COMPLETION FORMAT (use for request_job_completion): { "name": "AGI Job Completion · ", "description": "Final completion package for Job . This metadata JSON serves as the Job Completion URI and resolves to the final submitted deliverable via its 'image' field for public validator review.", "image": "ipfs://<CID of primary deliverable — any file type: PNG, TXT, PDF, JSON, etc. Not necessarily an image — this NFT metadata field points to your main deliverable>", "attributes": [ { "trait_type": "Kind", "value": "job-completion" }, { "trait_type": "Job ID", "value": "" }, { "trait_type": "Category", "value": "" }, { "trait_type": "Final Asset Type", "value": "<PNG | PDF | TXT | JSON | etc.>" }, { "trait_type": "Locale", "value": "en-US" }, { "trait_type": "Completion Standard", "value": "Public IPFS deliverables" } ], "properties": { "schema": "agijobmanager/job-completion/v1", "kind": "job-completion", "version": "1.0.0", "locale": "en-US", "title": "", "summary": "Brief description of what was submitted and how it satisfies the job spec.", "jobId": 0, "jobSpecURI": "ipfs://", "jobSpecGatewayURI": "https://ipfs.io/ipfs/", "finalDeliverables": [ { "name": "Primary deliverable", "uri": "ipfs://", "gatewayURI": "https://ipfs.io/ipfs/", "description": "What this file contains and how it satisfies the job spec" } ], "validatorNote": "Confirm the 'image' field resolves publicly and review against the job spec acceptance criteria.", "completionStatus": "submitted", "chainId": 1, "contract": "0xB3AAeb69b630f0299791679c063d68d6687481d1", "createdVia": "your-agent-name", "generatedAt": "", "submissionType": "Job Completion URI" } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional name for the pinned file (e.g. "job-spec-my-task")
metadataYesThe JSON metadata object to upload. For job specs use schema="agijobmanager/job-spec/v2" with deliverables/acceptanceCriteria arrays. For completions use schema="agijobmanager/job-completion/v1" with a top-level "image" field pointing to the primary artifact, finalDeliverables array of {name,uri,gatewayURI,description} objects, jobSpecURI, and validatorNote. The schema field is a plain string tag, not a URL.
pinataJwtYesYour Pinata JWT token (starts with "eyJ..."). Get one at https://app.pinata.cloud/developers/api-keys

TDQS

A4.8/5.0
Behavior4/5

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

With no annotations, the description carries the burden. It clearly states the tool returns an ipfs:// URI and requires a Pinata JWT. It also discloses the metadata schema requirements in detail. However, it does not mention potential costs, rate limits, or failure behavior (e.g., HTTP errors or invalid JWT), which would add further transparency.

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

Conciseness5/5

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

The description is long, but every sentence earns its place. The opening line is a punchy summary, followed by clear 'JOB SPEC FORMAT' and 'COMPLETION FORMAT' sections. The structure is logical and scannable, with each JSON example serving a concrete need. This is appropriate for a tool with complex input requirements.

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

Completeness5/5

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

Given the tool's complexity (nested objects, two distinct use cases) and the absence of an output schema, the description is complete. It covers purpose, usage ordering, authentication, return value, and provides exhaustive format templates. An agent has everything needed to call the tool correctly for both create_job and request_job_completion workflows.

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

Parameters5/5

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

Although the input schema already covers both parameters, the description goes far beyond by providing complete JSON examples for both job spec and completion metadata. The schema only gives brief hints; the description explains exact required fields, arrays, and formatting, adding substantial semantic value for the 'metadata' parameter.

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

Purpose5/5

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

The first sentence clearly states the tool's function: 'Upload JSON metadata to IPFS via Pinata and return the ipfs:// URI.' This uses a specific verb, resource, and expected output, and immediately distinguishes it from sibling job-management tools.

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

Usage Guidelines5/5

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

Explicit usage guidance is provided: 'Use this BEFORE calling create_job (upload the job spec) or request_job_completion (upload the completion proof).' It also specifies the prerequisite (Pinata JWT) with a link to obtain one, which fully helps an agent decide when to invoke this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool has a distinct purpose with clear boundaries: job lifecycle (create_job, apply_for_job, cancel_job, request_job_completion, finalize_job, expire_job), validation (approve_job, disapprove_job, dispute_job), metadata handling (fetch_job_metadata, upload_to_ipfs), and queries (list_jobs, get_job, get_agent_reputation, check_agent_identity, get_protocol_info, register_agent). No overlapping functionality exists.

Naming Consistency5/5

All 17 tools follow a consistent snake_case verb_noun pattern (e.g., create_job, list_jobs, fetch_job_metadata). The naming is highly predictable, with verbs like create, get, list, apply, approve, cancel, check, upload, and register consistently paired with relevant nouns.

Tool Count5/5

17 tools is well-scoped for a job management platform covering the full lifecycle from creation to completion, including validation, disputes, metadata handling, and queries. Each tool earns its place, with no redundancy, and the count aligns with the complexity of the domain.

Completeness5/5

The toolset provides complete coverage for the AGI Alpha job platform: full CRUD/lifecycle (create, list, get, apply, cancel, complete, finalize, expire), validation workflows (approve, disapprove, dispute), identity and reputation management (register_agent, check_agent_identity, get_agent_reputation), metadata handling (upload_to_ipfs, fetch_job_metadata), and protocol info. No gaps are apparent.

Resources