Skip to main content
Glama

canvas-mcp

by io.github.AvatarGaia
OverviewDiscussionsAdmin

发布知识库

publish_kb
DestructiveIdempotent

把一套整理好的 Markdown 发布成知识库（发布到我名下；带 slug 则同时配给那个岗位；带 owner=ws:<工作区id> 则发布成那个工作区的库，要求我是该工作区 owner/admin）。结构：wiki/index.md 是总目录（每篇一行：链接 + 一句摘要 + 更新日期，数字员工靠它挑页，摘要要准）；其余 wiki/<主题>/<文章>.md，一个概念一篇，标题用访客会问的说法，单篇别超过 6000 字。页面要带图片 / 视频 / 三维模型 / 外链时，在页里写一个 ```kb-media 围栏，一行一个「类型 | 标题 | 链接 | 说明」，类型 image / video / model(.glb) / link / embed(只认白名单站点)，链接用 https:// 或本站 /static/ /uploads/ /apps/ 路径——素材只放链接，不要把文件内容塞进来；数字员工回答时会把素材显示给访客。库主人可以开「只用已校验的页」，那时你新发或改过的页都是待校验，要人在网页上核对后才对访客生效，你不能自己批。规矩：①数字、日期、引文必须照原始资料逐字写，不改写不推算；②只收 wiki/ 下的 .md，原始资料不要发上来；③同名再发是整库替换，更新前先 read_kb 把现有页面读回来合并；④发布等于公开——岗位是匿名访客都能聊的，个人隐私、客户资料、令牌、内部运维内容一律不放（平台会拦身份证号和令牌，其它靠你自检）。checked 必须为 true 才会发。上限 200 个文件 / 单个 64KB / 合计 2MB。参数示例：{"name":"选课指南","checked":true,"files":[{"path":"wiki/index.md","content":"# Knowledge Base Index\n..."},{"path":"wiki/xuanke/rules.md","content":"# 选课时间与学分上限\n..."}]}（files 是数组，每项一个 {path, content}，不是 {路径: 内容} 的对象）。这是写操作，发之前跟用户确认库名和要不要配给岗位。

Input Schema

NameRequiredDescriptionDefault
nameNo库名：中英文、数字、- _，40 字以内。同名再发 = 整库替换
slugNo可选：发布后顺手配给这个岗位
filesYes这个库的全部页面，数组，每项 {path, content}：必须含 wiki/index.md；其余是 wiki/<主题>/<文章>.md
ownerNo可选：ws:<工作区id> = 发布成工作区的库（我须是该工作区 owner/admin）；不传 = 我名下
kbNameNoname 的别名
checkedYes自检通过才填 true：每个数字 / 日期 / 引文都能在原始资料里逐字找到；没有个人隐私、客户资料、令牌、内部运维内容

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / owner
      Added value: +{
+  "description": "可选：ws:<工作区id> = 发布成工作区的库（我须是该工作区 owner/admin）；不传 = 我名下",
+  "type": "string"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Even though annotations already flag destructiveHint=true and idempotentHint=true, the description adds substantial context: same-name republish is a whole-library replacement, checked must be true, hard limits (200 files / 64KB each / 2MB total), publication is public, and the 'verified-pages-only' mode makes new/edited pages pending review that the caller cannot self-approve. This is far beyond what the annotations convey.

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?

The purpose is front-loaded and almost every sentence carries operational value (index format, media fence, digit/date rules, privacy). It is dense and presented as one long paragraph with inline rule markers rather than scannable sections, which slightly hurts structure but the length is justified by the tool's complexity.

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 6-parameter write tool with no output schema, the description covers everything needed to call it correctly: directory conventions, per-page naming/size guidance, the kb-media fence grammar, byte/file limits, privacy constraints, verification behavior, and the user-confirmation step. No material gap remains.

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 genuinely useful gotcha for files: it is an array of {path, content}, not a {path: content} object, backed by a concrete JSON example. Owner/slug/name semantics are already fully in the schema, so the marginal value is limited to the format warning.

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?

The opening states a specific verb+resource: '把一套整理好的 Markdown 发布成知识库', and immediately distinguishes three publication targets (my own name, a role via slug, a workspace via owner=ws:<id>). This clearly separates it from read_kb and list_kbs, which read rather than publish.

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?

Explicitly gives when-to-use context and alternatives: before re-publishing under the same name, '更新前先 read_kb 把现有页面读回来合并', and it instructs confirming the library name and role assignment with the user beforehand. Nothing about routing or preconditions is left to inference.

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

All canvas-mcp toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources