Skip to main content
Glama

dialogbrain

by io.github.saloprj
OverviewDiscussionsAdmin

artifacts_set_access

Change an artifact's access level. 'shared' makes the unguessable link the capability (anyone-with-link); 'private' revokes that — the link 404s for anyone not signed into the workspace. Existing shared links keep the same URL when re-shared.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
artifact_idYesThe artifact to change.
access_levelNo'shared' (anyone-with-link) or 'private' (in-app only). OMIT to leave the access level unchanged — do that when the call only binds or unbinds a Telegram Mini App.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
telegram_web_app_agent_idNoThe agent woken by events from this page. It must own exactly one enabled webhook trigger — that trigger is what the events target. Not needed when unbinding (telegram_web_app_account_id=0).
telegram_web_app_account_idNoBind this artifact to a Telegram bot account (channel_account.id) so it can be opened as a Mini App from a `web_app` button and report verified events back. The artifact must already be shared (or be made shared in this same call). Pass together with telegram_web_app_agent_id. Pass 0 to UNBIND — the page stops being a Mini App and stops accepting events; telegram_web_app_agent_id is not needed to unbind. Setting access_level='private' also unbinds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  2. Added
  3. Removed
  4. Added

TDQS

A4.2/5.0
Behavior4/5

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

With annotations covering the safety profile (readOnlyHint=false, destructiveHint=false), the description still adds real behavior: 'shared' makes the unguessable link the capability, 'private' causes the link to 404 for anyone not signed into the workspace, and re-sharing preserves the URL. It omits that 'private' also unbinds a Telegram Mini App, though the schema carries that detail.

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 sentences, front-loaded with the action, then the two modes, then a re-share edge case. No filler, no restatement of the name or title, and each sentence adds distinct information.

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

Completeness4/5

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

The tool is non-trivial (Telegram Mini App binding, workspace scoping, enum + omit semantics), but the 100%-covered input schema carries those dimensions and there is no output schema to explain. The description fully covers the access-level dimension it is named for; only the interaction with Telegram binding is left entirely to the schema.

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 description coverage is 100%, so baseline is 3, but the description genuinely enriches the enum beyond the schema's terse 'shared (anyone-with-link) or private (in-app only)': it explains that the link itself is the capability and that revocation produces a 404. The URL-stability note further clarifies re-invocation semantics.

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 ('Change an artifact's access level') that is immediately distinguishable from the sibling artifacts_update (which handles content) and artifacts_get/list. The scope is tight enough that an agent knows exactly which operation this is without opening the schema.

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?

Usage is implied by the semantics of 'shared' vs 'private' rather than stated: an agent can infer when to pick each value, but the description never says when to call this tool versus artifacts_update, nor does it name alternatives or prerequisites. Adequate but with a clear gap.

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

All dialogbrain toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources