MCP for Claude & ChatGPT

Documents and reports

tuqui_artifact

Destructive

The workspace Library: everything you do with an artifact, in one place. action='list' browses (metadata only, enough for discovery); 'get' reads one — pass show:true when the person asked to SEE it and the document opens beside the conversation; 'save' creates a new one, or changes the one you name with artifact_id — use edits for a local change and content only when the page is genuinely being rewritten, and pass archived:true to take it out of the way (archived:false puts it back); every save goes live, so 'publish' only points the share link back at an older VERSION — what readers see, not who may see it; 'share' is the one about access (to and level, level='none' to take it away, or target='workspace' to move the reach); 'delete' destroys it and asks first. FIRST, if you are writing or replacing a page (a save with content): load the design contract with tuqui_skill(action='get', name='artifact-design') if available — the container lays paper, brand fonts and colour tokens; you design the page. edits, a data-only update and every read need none of this. Inside the Tuqui chat what you create, change or show already renders as a clickable card next to your reply: do NOT repeat the url as a markdown link in your prose. Only when called from an external agent via MCP (no card UI) present the returned url as a markdown link.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "tuqui_artifact"
  }
}

Input Schema

Name	Required	Description	Default
`to`	No	share, target='user': who to give it to — their EMAIL or name (a user id also works). They must already be a member of this workspace: sharing does not invite. target='group': the group's name. A list, so handing the same level to a team is one call.
`data`	No	A JSON data snapshot, validated against the artifact's data_schema. On update it only reaches the screen if the template reads `#tuqui-data`.
`kind`	No	save, new: what the artifact is — 'page' (default), 'report', 'presentation', 'app' (interactive tool), or 'doc' (markdown instead of a self-contained HTML page). list: only this kind.
`lang`	No	save: content language code (e.g. 'es', 'en').
`mine`	No	list: only artifacts created by the caller.
`show`	No	get: True when the PERSON asked to see or open this artifact — it opens beside the conversation. Leave it out when you are reading the page for yourself, to edit it or to quote a figure: a read is not a reason to take over their screen.
`edits`	No	save, existing: partial edits applied to the CURRENT content, in order — the rest of the page is kept byte for byte. Read it with action='get' first and copy each fragment exactly, whitespace included. Each `find` must match EXACTLY ONE place: zero matches or several are rejected and no version is created, so extend `find` with surrounding text until it is unique. Cannot be combined with a full rewrite of the page.
`level`	No	share: 'usar' or 'editar' — the two levels of the picker, Spanish because the spec fixes them as the domain vocabulary of the model (compartir-unificado §10). 'none' takes the access away: it revokes the person's share, or closes the object back to the people invited. 'link' is a reach only the Library offers (anyone in the workspace with the URL).
`limit`	No	list: page size.
`title`	No	save: the document's title.
`action`	Yes	REQUIRED. What to do with the Library.
`offset`	No	list: skip this many; use the next_offset of a previous call.
`search`	No	list: case-insensitive match on title/description.
`target`	No	share: who gets it. 'user' (default) gives it to people; 'group' to whoever is in a group; 'workspace' moves the reach, handing the level to every member at once.
`content`	No	save: the page (self-contained HTML, or markdown for kind='doc'). On an existing one it is a FULL replacement — for a local change prefer `edits`, because everything you do not retype here is lost.
`version`	No	get: version to read (omit for the latest). publish: version to serve.
`archived`	No	save: True takes the artifact out of the way — it leaves the default listing and its internal share link stops resolving, but nothing is deleted. False puts it back. Prefer this over delete when in doubt.
`visibility`	No	save, new: who reaches it inside the workspace.	private
`artifact_id`	No	UUID. Required for get, publish, share and delete; on save it means UPDATE this one instead of creating a new artifact.
`data_schema`	No	save, new: JSON Schema the artifact's `data` must satisfy from then on.
`description`	No	save: one line about it.
`consent_token`	No	The approval a person gave for THIS call in Tuqui. Bound to these arguments and valid once.
`change_summary`	No	save: optional, one line about this version (shown in the version history).
`content_sha256`	No	save: `sha256sum` of a file on your disk, used as `content` instead of retyping it. The first call saves nothing and returns a curl command: run it, then repeat the call.
`conversation_id`	No	list: only artifacts created from this conversation (UUID).
`include_archived`	No	list: include the ones taken out of the way.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 2, 2026

changedInput schema / properties / change_summary / description

Previous value: -"save: one line describing what changed (shown in the version history)."New value: +"save: optional, one line about this version (shown in the version history)."

changedInput schema / properties / description / description

Previous value: -"save, new: one line about it."New value: +"save: one line about it."

changedInput schema / properties / lang / description

Previous value: -"save, new: content language code (e.g. 'es', 'en')."New value: +"save: content language code (e.g. 'es', 'en')."

changedInput schema / properties / title / description

Previous value: -"save, new: the document's title."New value: +"save: the document's title."

First observedNov 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only say destructiveHint=true and readOnlyHint=false; the description does the real work of drawing the destructive boundary — delete 'destroys it and asks first', archived 'nothing is deleted', every save 'goes live', and publish is not access control. It also discloses the output-side behavior (a clickable card renders in Tuqui chat, so do not repeat the URL; only external MCP callers should get a markdown link), which annotations cannot express.

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?

Front-loaded with the resource and then walked action-by-action in enum order, which makes it navigable; every clause carries operational weight for a 26-parameter, six-action tool. It reads as one dense paragraph with capitals for emphasis rather than scannable structure, and a few points (delete asks first) are partly restated in the schema.

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?

For a 26-param multi-action tool with no output schema, it covers the crucial unknowns: which actions mutate, how the result surfaces to the user, the prerequisite design-contract load, and the ordering constraint of reading before editing. Gaps are minor — list/pagination return shape and failure behavior live in the schema rather than the description.

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?

Coverage is 100%, so 3 is the floor, and the description exceeds it by disambiguating the pairs an agent would most likely confuse: edits vs content (partial vs full replacement), show vs a private read, and publish vs share ('what readers see, not who may see it'). The remaining enum values (level, target, kind) are clarified in the schema itself rather than here, so it stops short of a 5.

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?

Names a specific resource ('the workspace Library') and then enumerates each action with a concrete verb: list browses, get reads, save creates/updates, publish repoints a version, share grants access, delete destroys. An agent can map every enum value to a distinct meaning. It loses a point only because it never distinguishes itself from plausible siblings such as tuqui_docs or tuqui_kb, which an agent may hesitate between.

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 selection rules throughout: 'pass show:true when the person asked to SEE it', 'use `edits` for a local change and `content` only when the page is genuinely being rewritten', archived:true 'to take it out of the way', and delete only for genuine destruction. It even names the prerequisite companion call (tuqui_skill(action='get', name='artifact-design')) and scopes it: 'edits, a data-only update and every read need none of this.'

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

All MCP for Claude & ChatGPT tools Inspect

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.