Skip to main content
Glama
OktoLabsAI

okto-nexus

by OktoLabsAI

artifact_put

Register file, text, JSON, Markdown, or HTML artifacts in a resolved workspace from a path or inline UTF-8 content. Store metadata and classify artifacts for Nexus-managed projects.

Instructions

Register a file/text/json/markdown/html artifact in the resolved workspace. Docs: okto-nexus://reference/tool-docs/artifacts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoHuman-friendly name/label for the artifact (optional).
pathNoFilesystem path to import into Nexus-managed artifact storage (must stay within the workspace root). Provide this OR content - at least one REQUIRED.
contentNoUTF-8 content stored outside the database (bounded by max_inline_bytes; json must be well-formed). Provide this OR path - at least one REQUIRED.
metadataNoFree-form JSON object stored with the artifact (optional).
project_rootYesAbsolute path to the project (defines the workspace scope).
artifact_typeYesArtifact classification - one of: file, text, json, markdown, html. REQUIRED.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.10

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about overwrite/duplicate behavior, idempotency, required permissions, size limits, or failure modes. 'Resolved workspace' hints at a dependency on workspace_resolve but does not explain it.

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?

Two short, front-loaded sentences with a useful docs pointer and no filler. Slightly terse for a write operation, but nothing is wasted.

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

Completeness2/5

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

This is a mutation tool with no annotations and no output schema referenced in the description, so ambiguity about what a successful registration returns or does to existing artifacts is significant. The schema covers inputs and the docs link covers unspecified detail, but the description itself leaves the agent without the behavioral context needed to call it safely.

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 all six parameters (including the path-or-content exclusivity rule and the artifact_type enum-in-prose) are already documented in the schema. The description adds no parameter meaning beyond what is structured, so the baseline of 3 is appropriate.

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 ('Register') and resource ('artifact') plus the accepted artifact types and the workspace scope. It is clearly distinguishable from artifact_get by direction, though it doesn't explicitly name that sibling as the converse operation.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as shared_md_render or artifact_get, and no prerequisites or exclusions. The only pointer is an external docs URI, which an agent cannot resolve inline.

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