Skip to main content
Glama
IEZhu

Agents-Core

by IEZhu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Publish immutable text artifact

artifact_publish
Idempotent

Publish immutable, persistent text artifacts without starting a model. Use source_path for large files so their bodies stay out of the model context.

Instructions

Publish an immutable persistent text artifact without starting a model.

Prefer source_path for large files so their bodies need not pass through the
model. Content identity is SHA256 within this workspace; duplicate publication
retains the first descriptor. Files survive Redis and broker restarts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesArtifact display name, 1..120 characters; no path separators or control characters.
contentNoExactly one of content or source_path. UTF-8 content, at most 4 MiB; not logged.
media_typeNotext/plain, text/markdown or application/json; default text/plain.text/plain
source_pathNoExactly one of source_path or content. Regular UTF-8 file relative to the authenticated workspace root; no traversal/symlinks. Safe file capture requires POSIX.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv26.10.16

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly=false, idempotent=true, destructive=false, openWorld=false), but the description adds semantics an agent cannot infer from them: content identity is SHA256 within the workspace, duplicate publication retains the first descriptor, and files survive Redis and broker restarts. These dedup and durability guarantees materially affect retry and reuse decisions.

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?

Three short, front-loaded statements: the action, the input-mode preference, and the identity/persistence semantics. No filler, and the most decision-relevant information (what it does, how to feed it) comes first.

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?

For a non-destructive, idempotent publish tool with a full schema and an output schema (so return values need no explanation), the description covers the remaining unknowns: dedup behavior, durability across restarts, and input-mode tradeoffs. Nothing essential an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds a decision heuristic not present in the schema: prefer source_path for large bodies to avoid passing them through the model. The exactly-one-of constraint and formatting limits are left to the schema, which documents them thoroughly.

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?

States a specific verb and resource ('Publish an immutable persistent text artifact') plus a distinguishing constraint ('without starting a model') that separates it from sibling generation tools like local_generate. It also implicitly contrasts with artifact_read and the artifact_manifest_* family by scoping itself to publication.

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

Usage Guidelines4/5

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

Gives a clear routing rule: 'Prefer source_path for large files so their bodies need not pass through the model.' This is actionable context for choosing between the two mutually exclusive input modes. It stops short of naming when NOT to use this tool or pointing to a specific alternative sibling.

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