The Artifacta MCP Server is an artifact store for AI agents, enabling them to persist, manage, and share run outputs (files, reports, datasets, build results) across sessions with content-hash deduplication and secure access.
Verify identity & quota (whoami): Confirm authentication and retrieve tenant info, plan tier, storage usage, request counts, and rate limits.
Upload artifacts (store_artifact): Upload via inline base64 (≤10 MB) or local file path (≤500 MB), tagged with session/agent IDs and custom metadata. Supports idempotency keys for crash-safe retries.
Upload large files (request_upload_url + complete_upload): Two-phase upload for files up to 5 GB — reserve a presigned R2 PUT URL, upload directly, then finalize (Pro plan only).
Fetch artifact metadata (get_artifact): Retrieve filename, content type, size, content hash, session/agent IDs, custom metadata, expiry, and timestamps for a specific artifact.
Download artifacts (get_artifact_download_url): Generate a short-lived (1-hour) presigned URL to download artifact bytes directly from Cloudflare R2.
List & filter artifacts (list_artifacts): Filter by session, agent, filename, content type, date ranges, or custom metadata key/value pairs, with cursor-based pagination.
List sessions (list_sessions): View active sessions with artifact counts, seal status, and activity timestamps.
Seal sessions (seal_session): Lock a session to prevent further artifact uploads.
Create public share links (create_download_link): Generate stable, expiring public links for sharing artifacts with humans (requires --allow-destructive).
Delete artifacts (delete_artifact): Soft-delete an artifact (requires write confirmation).
Safety: Local file uploads are path-confined to an allow-list; destructive tools are gated behind --allow-destructive.
Provides optional integrations for LangChain/LangGraph to persist and share artifacts from agent runs.
Provides optional integrations for LangChain/LangGraph to persist and share artifacts from agent runs.
Provides adapters for the OpenAI Agents SDK to enable AI agents to store and retrieve artifacts.
Official MCP server for Artifacta — an artifact store purpose-built for AI agents. Agents persist run outputs (files, reports, datasets, build results) with session and agent metadata, hand them off across sessions, and share them via expiring download links. Content-hash dedup means re-storing the same bytes is free.
Listed in the official MCP registry
as io.artifacta/mcp.
Two implementations with the same tool surface, error contract, and path-confinement engine:
Directory | Package | Runtime |
Node 20+ | ||
Python 3.10+ |
For Claude Code, the fastest path is the plugin marketplace this repo doubles as — it wires up the hosted server and a skill that persists run outputs automatically:
/plugin marketplace add SagaPeak/artifacta-mcp
/plugin install artifacta@artifactaThis bundles the same hosted MCP connection as the Quick start below plus the
persisting-outputs skill (/artifacta:persisting-outputs, or it auto-triggers
when a session has outputs worth saving). Update the plugin with
/plugin marketplace update artifacta. See the
plugin setup guide.
Related MCP server: Structured-sh
The fastest way to connect is the hosted server — no install, no API key:
claude mcp add --transport http artifacta https://mcp.artifacta.io/mcpOn first use your client self-registers via OAuth Dynamic Client Registration
(PKCE) and opens a browser to authorize — no ak_live_ key to copy or store.
See the hosted setup guide.
For headless, air-gapped, or CI environments where a browser OAuth flow isn't available, run the package locally over stdio with an API key. Get a key at app.artifacta.io/dashboard/keys, then add to your MCP client config (Claude Desktop, Claude Code, Cursor, or any MCP client):
{
"mcpServers": {
"artifacta": {
"command": "npx",
"args": ["-y", "@artifacta-mcp/mcp"],
"env": {
"ARTIFACTA_API_KEY": "ak_live_..."
}
}
}
}Or run the Python implementation with pipx run artifacta-mcp.
See the per-package READMEs for config-file profiles, path confinement
(--allow-path), destructive-tool gating (--allow-destructive), and
troubleshooting: TypeScript ·
Python.
Tool | Description |
| Verify credentials; returns tenant and plan info |
| Upload an artifact from inline content or a local path |
| Two-phase presigned upload for large files |
| Fetch artifact metadata by ID |
| Get a presigned download URL (1h expiry) |
| List/filter artifacts by session, agent, or metadata |
| List active sessions |
| Seal a session so no further artifacts can be added (gated behind |
| Create a public expiring share link (gated behind |
| Soft-delete an artifact (gated behind |
| Publish an artifact as a public page at |
| Take down an artifact's public page; the artifact itself is untouched; idempotent |
Plus MCP resources for whoami, artifact metadata, artifact bytes, and
sessions.
Safety defaults: local-file uploads are confined to an explicit --allow-path
allow-list, and destructive tools (public share links, deletes, session seals)
are hidden from clients that can't confirm writes unless --allow-destructive
is passed. publish_artifact and unpublish_artifact are idempotent write
operations, not destructive ones — they are not gated behind
--allow-destructive.
Hosted OAuth connections (mcp.artifacta.io) add a second layer: the consent
screen grants one of three scopes — artifacts:read ⊆ artifacts:write ⊆
artifacts:destroy. All 13 tools are always advertised in tools/list;
calling a tool the token wasn't granted for returns a tool error with code
insufficient_scope naming the missing scope, and the fix is to re-authorize
with the broader scope. Scope gating applies only to hosted OAuth —
ak_live_ API keys and local stdio remain full-access, using
--allow-destructive / confirmation flags instead.
The Python package ships optional adapters for
OpenAI Agents SDK (pip install 'artifacta-mcp[openai-agents]') and
LangChain/LangGraph (pip install 'artifacta-mcp[langchain]').
Full docs at docs.artifacta.io/mcp/overview.
# TypeScript
cd typescript && npm install && npm test
# Python
cd python && python -m venv .venv && source .venv/bin/activate
pip install -e '.[dev]' && pytestThis repository is published from the Artifacta monorepo; issues and PRs are welcome here.
MIT — see LICENSE.
Finalize an artifact previously reserved via request_upload_url after the bytes have been PUT to the presigned URL. Server verifies the blob, computes the content hash, transitions the artifact from pending to active, and increments tenant usage. Calling this on an already-active artifact is idempotent and returns the existing record. Calling before the PUT completes returns upload_not_found — wait and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains server verifies blob, computes content hash, transitions state from pending to active, increments tenant usage, idempotency, and error condition. Annotations only indicate not read-only, so description adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each serving a purpose: purpose, steps, idempotency, error handling. No wasted words, front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool (1 param, no output schema), description covers purpose, behavior, state transitions, error case, and retry guidance. Agent can confidently invoke and handle responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter artifact_id has 0% schema description coverage. Description uses artifact_id in error message but does not explain its origin (e.g., from request_upload_url) or nuance. Schema pattern provides format, but description adds minimal semantic value beyond context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the tool 'Finalize an artifact previously reserved via request_upload_url after the bytes have been PUT to the presigned URL'. It clearly identifies the verb (finalize), resource (artifact), and prerequisite step, distinguishing it from the sibling tool request_upload_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (after PUT) and when not (before PUT completes, returns upload_not_found; wait and retry). Also mentions idempotency on already-active artifacts. Lacks direct comparison to store_artifact but still gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch metadata for a single artifact by ID: filename, content type, size, content hash, session/agent IDs, custom metadata, expiry, creation timestamp. Does NOT return the file bytes — call get_artifact_download_url for that. Returns artifact_not_found for unknown IDs, artifact_already_deleted (HTTP 410) for soft-deleted ones, artifact_expired (410) for those past their TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, which matches the description. The description adds behavioral details beyond annotations, such as returning specific error codes for unknown IDs, soft-deleted artifacts, and expired artifacts (HTTP 410).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, read-only, no output schema needed), the description fully covers the behavior, return fields, and error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter artifact_id with a regex pattern, which is self-explanatory. The description does not add additional meaning beyond what the parameter name and schema imply, but it's sufficient for the simple parameter. With 0% schema description coverage, the description could elaborate, but the param is well-defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches metadata for a single artifact by ID, listing specific metadata fields (filename, content type, size, etc.). It distinguishes itself from the sibling tool get_artifact_download_url which returns file bytes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains what the tool does and what it does NOT do (return file bytes), directing users to call get_artifact_download_url for that. It also lists specific error conditions (artifact_not_found, artifact_already_deleted, artifact_expired), providing clear guidance on expected behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a short-lived presigned URL (1 hour) the agent can use to download the artifact's bytes directly from Cloudflare R2. Use this when the agent itself needs to consume the file. For sharing with humans, use create_download_link instead — that produces a stable dl.artifacta.io/lnk_… URL with configurable expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying the URL is short-lived (1 hour) and from Cloudflare R2. No contradictions. Additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core function. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully covers purpose, usage guidance, output nature (presigned URL, 1 hour), and alternative. Complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter `artifact_id` with 0% schema description coverage. The description does not explain the parameter format or source beyond what the schema regex provides. However, the parameter is simple and its purpose is implied by the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a presigned URL for downloading artifact bytes from Cloudflare R2 with a 1-hour expiry. It distinguishes from the sibling tool `create_download_link` which is for sharing with humans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the agent itself needs to consume the file. For sharing with humans, use `create_download_link` instead.' Provides clear when-to-use and when-not-to-use guidance with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List artifacts owned by the calling tenant, newest first. Supports filters by session_id, agent_id, filename (exact match), content_type, created_after / created_before (ISO 8601), and one or more metadata.<key>=<value> pairs (multi-key requires Pro). Returns a page of artifact records and a next_cursor to fetch the next page. Use this to discover what an agent or pipeline produced when you only know a session or agent ID.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | ||
| agent_id | No | ||
| filename | No | ||
| content_type | No | ||
| created_after | No | ||
| created_before | No | ||
| metadata | No | ||
| limit | No | ||
| cursor | No | Opaque cursor from previous page's next_cursor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms a read operation by stating 'List artifacts'. It discloses behavioral traits like default ordering ('newest first') and pagination via 'next_cursor', which go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the core purpose, then lists filters, and ends with usage guidance. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description covers all filter options and pagination. It mentions returning a 'page of artifact records' and a 'next_cursor', which is sufficient. Minor gap: no detail on the structure of each artifact record, but the tool is likely used with other tools that provide that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, but the description compensates by explaining all filter parameters: session_id, agent_id, filename, content_type, created_after/before, and metadata key-value pairs. It also notes that multi-key metadata requires Pro, adding semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List artifacts'), the resource ('owned by the calling tenant'), and the default ordering ('newest first'). It distinguishes from siblings like get_artifact (single artifact) and store_artifact (write operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: 'Use this to discover what an agent or pipeline produced when you only know a session or agent ID.' It mentions supported filters and pagination but does not explicitly state when not to use it (e.g., for single artifact retrieval).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List session IDs synthesized from the calling tenant's artifacts, ordered by most recent activity. Each entry includes artifact count, seal status, and first/last activity timestamps. Sessions are not first-class — they exist only as long as artifacts reference them.
| Name | Required | Description | Default |
|---|---|---|---|
| created_after | No | ||
| created_before | No | ||
| limit | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true; description adds that sessions are not first-class and exist only as long as artifacts reference them, and details the returned fields. This adds behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear, front-loaded information. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While purpose is clear, the description omits usage guidance for parameters like time range and pagination. For a list tool with four parameters and no output schema, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain any of the four parameters (created_after, created_before, limit, cursor). Description must compensate for low coverage but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists session IDs synthesized from artifacts with ordering and entry details. It is specific but doesn't explicitly differentiate from sibling tools like list_artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description implies context (artifacts) but provides no when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reserve a presigned R2 PUT URL for a file too large to send through store_artifact (over 500 MB up to 5 GB). Returns an upload_url, headers to include in the PUT, and an artifact_id in pending state. The agent (or its environment) PUTs the bytes directly to R2, then calls complete_upload. Pro plan only. Most agents should use store_artifact and let the MCP server pick the path automatically.
Not retry-safe: this endpoint does not support idempotency keys, so on an HTTP 5xx or network error the reservation may or may not have been created. Do NOT blindly retry — the error guidance tells you to first call list_artifacts with the same session_id/agent_id to detect any pending artifact, so you don't create a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| content_type | Yes | ||
| size_bytes | Yes | ||
| session_id | No | ||
| agent_id | No | ||
| metadata | No | ||
| ttl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false. Description adds important context about idempotency and retry handling, but could detail more edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused paragraphs: purpose/alternative and retry warning. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return values and retry safety, but missing explicit parameter explanations for metadata and ttl given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description implies usage of parameters but does not explain each parameter individually (e.g., metadata, ttl). Provides enough for basic understanding but not full detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specifically describes reserving a presigned R2 PUT URL for files too large for store_artifact (over 500 MB up to 5 GB). Distinguishes from sibling tool clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (large files), when not to (most should use store_artifact), and warns about retry safety with alternative detection approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file as a new artifact in a single call. Provide EITHER up to ~10 MB of base64-encoded bytes via content, OR a local filesystem path that the MCP server reads and streams as multipart/form-data (up to 500 MB). For files larger than 500 MB, use request_upload_url (Pro only) instead — store_artifact returns file_too_large for them. Tags the artifact with session_id / agent_id / metadata for later retrieval and returns the full artifact record including its new artifact_id and content_hash.
Path uploads are confined. The path argument is constrained to the launcher-configured allow-list (default: the MCP server's CWD). Paths outside the allow-list, paths traversing symlinks out of it, and paths to known-sensitive locations (~/.ssh, ~/.aws, /etc/, etc.) are refused with invalid_request.
For crash-safe retries, supply your own idempotency_key (any string ≤256 chars): a replay within 24h returns the original artifact and never double-bills. If you omit it, the server auto-generates one and returns it under _meta.idempotency_key, but that key protects only in-process retries within a single call — it is lost if the server restarts, so pre-commit your own key when durability matters.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| content | No | Base64-encoded bytes. Use for content under 10 MB or when no local path is available. | |
| path | No | Absolute local path inside the launcher-configured allow-list. The MCP server reads and streams this as multipart. Mutually exclusive with `content`. Paths outside the allow-list are refused. | |
| content_type | No | MIME type. If omitted, guessed from filename. | |
| session_id | No | ||
| agent_id | No | ||
| metadata | No | ||
| ttl | No | Duration suffix (e.g. `7d`, `30d`) or `never` (Pro only). Defaults to plan default. | |
| idempotency_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, readOnlyHint=false), description details idempotency guarantees, return value (full artifact record with artifact_id and content_hash), tagging behavior, and path confinement rules including sensitive locations refused. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose, then modes, limits, alternatives, return info, constraints, and idempotency. Each sentence adds value, though slightly verbose; could be more concise but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return value (full artifact record with artifact_id and content_hash). It covers all essential aspects: input modes, size limits, path constraints, idempotency, tagging, and error conditions. Complete for an upload tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 44% schema description coverage, the description compensates by clarifying size limits, streaming behavior, path restrictions, idempotency mechanics, and tagging. It adds significant meaning beyond the schema, especially for content, path, and idempotency_key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Upload a file as a new artifact in a single call' and specifies two distinct input modes (base64 content or local path). It distinguishes from siblings like list_artifacts and get_artifact by being the upload tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance: recommends request_upload_url for files >500 MB, describes path allow-list constraints, and explains idempotency_key usage for crash-safe retries. Also notes conditions that cause errors (file_too_large, invalid_request).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the calling tenant's identity, plan tier, current usage counters (storage bytes, monthly requests, active links), and rate limits. Use this once at the start of an agent run to confirm authentication and to size subsequent operations against quota. Free of side effects and quota-cheap.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true. The description adds 'Free of side effects and quota-cheap', which goes beyond annotations by disclosing quota cost and confirming no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with return values, then usage guidance, then behavioral note. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description sufficiently covers return values, usage context, side effects, and quota implications. For a zero-parameter info tool, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters and schema description coverage is 100%. With no parameters, baseline is 4; description does not need to add param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'calling tenant's identity, plan tier, current usage counters, and rate limits', using a specific verb and resource. It distinguishes well from sibling tools which handle uploads, artifacts, and sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use this once at the start of an agent run to confirm authentication and to size subsequent operations against quota.' No explicit when-not or alternatives, but the sibling tools are unrelated, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0complete_uploadget_artifactget_artifact_download_urllist_artifactslist_sessionsrequest_upload_urlstore_artifactwhoamiScored across 8 tools
Each tool has a distinct purpose: upload (store_artifact vs request_upload_url/complete_upload), download (get_artifact_download_url vs get_artifact for metadata), listing (list_artifacts vs list_sessions), and identity (whoami). No overlaps.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., complete_upload, get_artifact, list_artifacts, store_artifact). Even 'whoami' fits as a verb phrase.
With 8 tools, the set is well-scoped for an artifact management server. Each tool covers a necessary operation without bloat.
Core lifecycle operations (upload, download, list, retrieve metadata) are covered, but missing update and delete tools, which is a minor gap.
Artifact store for AI agents — read, write, and search files by path; share by rendered URL.
MCP-first toolbox for agents: KV storage, auth, queue, and utility tools. Free in early access.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
