MCP for Claude & ChatGPT

Manage the knowledge base

tuqui_kb

Destructive

Read and manage the knowledge base — the files and cloud folders the chat reads from: the user's own workspace knowledge. Questions about the product Tuqui itself (how to use it, prices, plans, permissions) go to tuqui_docs. scope='workspace' is the whole workspace (any member can read; only an admin or owner can change it); scope='project' is one project's own, and takes 'project_id' (any member of it can read; 'editor' or above IN THAT PROJECT can change it); scope='agent' is one agent's own files, and takes 'agent_id' (only who may edit that agent can read or change them). action='list' returns its files and folders; 'add' takes files the person attached to THIS conversation (by filename), a file from a cloud drive (Drive, OneDrive...), or a folder that keeps re-syncing; 'remove' takes 'resource_id' for a file or 'folder_id' for a folder. A folder's imported files come and go with it — remove the folder, not its files one by one. 'sync' re-reads the linked folders now; they already re-sync on their own whenever the base is listed, so only ask for it when something was JUST added to the folder and has to be there this minute.

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>",
      "scope": "<scope>"
    },
    "name": "tuqui_kb"
  }
}

Input Schema

Name	Required	Description
`url`	No	Link to the file or folder, if known.
`name`	No	Name of the cloud file or folder.
`cloud`	No	Which cloud the file or folder id comes from: the one whose tools gave it. Only needed when more than one is connected.
`scope`	Yes	REQUIRED. 'workspace' applies to every chat in the workspace; 'project' only to that project's chats; 'agent' only to what that agent reads.
`action`	Yes	REQUIRED. 'save' adds a source, 'delete' takes one out, 'sync' re-reads a linked folder. ('add' and 'remove' were the old names for the first two.)
`agent_id`	No	REQUIRED when scope='agent'. The agent's UUID, from tuqui_agent.
`folder_id`	No	For 'remove': the folder's UUID. For 'sync': the one folder to re-read — omit it to re-read every folder of the scope.
`mime_type`	No	MIME type of the cloud file.
`project_id`	No	REQUIRED when scope='project'. The project's UUID.
`resource_id`	No	For 'remove': the file's UUID.
`connector_id`	No	The connector to read it through. Only needed when the workspace has more than one of the same cloud.
`consent_token`	No	The approval a person gave for THIS call in Tuqui. Bound to these arguments and valid once.
`drive_file_id`	No	A file id from a connected cloud drive's tools to reference (not copied — read on demand); pass 'name' and 'mime_type' with it, and 'cloud'.
`drive_folder_id`	No	A folder id from a connected cloud drive's tools. The folder stays LIVE: its documents import as individual files and re-sync, so adding a folder can add many files.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 6, 2026

addedInput schema / properties / agent_id

Added value: +{
+  "description": "REQUIRED when scope='agent'. The agent's UUID, from tuqui_agent.",
+  "type": "string"
+}

changedInput schema / properties / scope / description

Previous value: -"REQUIRED. 'workspace' applies to every chat in the workspace; 'project' only to that project's chats."New value: +"REQUIRED. 'workspace' applies to every chat in the workspace; 'project' only to that project's chats; 'agent' only to what that agent reads."

changedInput schema / properties / scope / enum

Previous value: -[
-  "workspace",
-  "project"
-]New value: +[
+  "workspace",
+  "project",
+  "agent"
+]

First observedNov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the destructiveHint=true annotation by naming what is destroyed and how: a folder's imported files come and go with it, so remove the folder not its files one by one. It also discloses the permission model per scope (any member reads workspace; only admin/owner mutates; editor+ in that project; agent-edit rights for agent scope) and that linked folders self-resync on listing.

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 purpose and the sibling routing, and every clause carries information. It is a single dense paragraph with heavy parenthetical nesting, so the scope/action rules are harder to scan than they need to be.

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 14-parameter, mutation-capable tool with no output schema, it covers the essentials: scope permissions, action meanings, folder cascade behavior, and sync semantics. Gaps are minor and mostly covered by the schema, though the description never mentions the consent_token approval flow or how cloud/connector selection is scoped.

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 baseline is 3, and the description adds real meaning on top: scope-to-permission mapping, what 'list' returns, and that 'add' accepts conversation attachments by filename, a cloud-drive file, or a re-syncing folder. However it consistently uses 'add'/'remove' while the action enum is list/save/delete/sync, forcing the agent to reconcile the naming from the schema note.

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 concrete verb+resource ('Read and manage the knowledge base — the files and cloud folders the chat reads from') and immediately bounds the domain as 'the user's own workspace knowledge'. It also names the sibling it is not, tuqui_docs, with the exact condition that routes there (product/pricing/plan/permission questions).

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 when-to-use routing to tuqui_docs, per-scope explanations of who can read vs change, and a conditional rule for 'sync' ('only ask for it when something was JUST added to the folder and has to be there this minute'). It also states the alternative to per-file removal when a folder is the source.

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.