Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Meet Rupert MCP Server ask the AI how to set up a new hire"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets Claude work with the Meet Rupert knowledgebase (https://app.meetrupert.com): search and read documentation, ask the RAG AI questions (one-shot or in a conversation), and create/edit documents.
Node 20+ / TypeScript ESM, the official @modelcontextprotocol/sdk over stdio,
built with tsup.
Tool | Description |
| Search documents by title; returns ids, titles, status, categories (paginated). |
| Read a document by id; body returned as Markdown. |
| Create a document from Markdown. Defaults to draft (not AI-searchable) unless |
| Edit a document; omitted fields are preserved. |
| List categories with ids and document counts (for tagging / retrieval scoping). |
| Upload an image from a file path or HTTPS URL (never base64) and get a |
| List a document's images with their ids and whether they still resolve in storage. |
| Write an image to a path, or return a short-lived signed URL. Reports size + sha256. |
| Remove an image's reference from a document. Does not delete the stored file — see Attachments. |
| Ask a one-shot natural-language question; returns an answer + source documents. |
| Start a multi-turn conversation thread; returns a |
| Ask a question within a thread (remembers prior context). |
| List recent conversation threads to resume. |
Related MCP server: BookStack MCP Server
Meet Rupert has no API-key / service-token auth, so this server logs in as a
real user via POST /api/login/local, caches the short-lived JWT access token,
and silently re-authenticates when it nears expiry or on a 401. All requests
are scoped to the user's organisation, which is auto-resolved from the login
response (override with MEETRUPERT_ORG_ID).
The two "ask" tools consume the platform's text/event-stream RAG endpoints and
return the fully-accumulated answer plus its sources. Document content is
stored as Tiptap JSON and transparently converted to/from Markdown so Claude can
read and author documents in plain text.
Images use the platform's existing presigned-upload flow: the server asks for a
presigned PUT, uploads the bytes itself, and stores the returned storage key in
a Tiptap image node — the same representation the web editor produces. Reading
an image back goes through a short-lived media token. See
Attachments.
Tip: Create a dedicated low-privilege service user (role
editor) in Meet Rupert for this server rather than using a personal admin login.
Documents can embed images. The workflow is two calls:
create_attachment { path: "C:/Users/you/Pictures/step4-poll-fileset-500.png" }
→ { attachmentId: "9f3c1a2e-….png",
contentLength: 92324,
sha256: "…",
markdownRef: "" }
create_document { title: "New Defect Form",
content: "# Steps\n\n" }create_document and update_document resolve every attachment://<id> to its
storage key at save time. read_document renders stored images back as
attachment:// refs, so a document can be read, edited and written back without
losing them.
The caller never supplies image bytes — it names a source and the server reads it. This is not a stylistic choice. A model cannot reliably reproduce a large base64 payload into a tool-call argument: in testing an 18,880-byte payload arrived as 7,312 bytes, silently corrupting the file with no error raised. Anything above roughly 10 KB is unsafe, which rules out essentially every real screenshot.
Reading server-side also makes the returned contentLength and sha256 facts
about the file rather than facts about the transport, so a caller can verify them
against the source. Compare with Get-FileHash -Algorithm SHA256 <file>.
image/png, image/jpeg, image/webp and image/gif, up to 10 MB. The type is
determined from the file's magic bytes, not its extension, and a file whose
extension disagrees with its content is rejected rather than uploaded.
SVG is rejected outright — it can carry script and external references, and the
platform's own content-type allowlist excludes it. Non-image files (PDF, .docx,
plain text) are also rejected: the platform has no storage for them.
These follow from the platform having no attachment entity — images are presigned S3 uploads referenced by storage key, with no table, no metadata and no delete endpoint. Removing them needs a backend change, not a change here.
Images only. No PDF, .docx or text attachments.
delete_attachment unlinks, it does not delete. It removes the reference
from a document; the stored object remains and stays readable by anyone holding
a signed URL. Don't tell a user their file has been erased.
No garbage collection. Attachments uploaded but never referenced by a saved
document are reported on stderr after MEETRUPERT_ATTACHMENT_TTL_MS, not
reclaimed. (Orphans are not unique to this server — the web editor presigns an
upload before the user saves and records nothing, so an abandoned edit leaks an
object the same way.)
filename and sha256 are advisory. They are returned at creation and not
persisted, because there is nowhere to persist them.
path fails closed. Reads are confined to MEETRUPERT_ATTACHMENT_DIRS,
which is empty by default, so path is refused until an operator opts in.
Symlinks are resolved before the containment check and containment is compared
on path segments, so neither a symlink nor a .. nor a same-prefix sibling
directory (/srv/uploads-evil vs /srv/uploads) can escape.
source_url is SSRF-hardened. HTTPS only; private, loopback, link-local,
CGNAT and cloud-metadata ranges are blocked after DNS resolution, with the
connection pinned to the vetted address so a rebind cannot land elsewhere;
redirects are not followed; connect and read timeouts apply; and the size cap is
enforced per chunk while streaming, aborting the transfer rather than checking
after the download completes.
Tenancy. Storage keys are always built from the resolved org id, never from caller input, so an attachment is only reachable within the workspace that created it. The backend independently enforces the same prefix.
Logging. Filenames, byte counts and checksums only — never file contents, and attachment bytes are never placed in an error message or stack trace. Fetched URLs have credentials and query strings redacted.
npm install
cp .env.example .env # then fill in credentials
npm run build.env)Variable | Required | Description |
| yes | Service user's email. |
| yes | Service user's password. |
| no | API base URL incl. |
| no | Override the organisation. Defaults to the logged-in user's org. |
| no | Directories |
| no | Per-attachment size cap. Defaults to |
| no | How long before an unreferenced attachment is reported as an orphan. Defaults to |
claude_desktop_config.json or .claude/settings.json){
"mcpServers": {
"meetrupert": {
"command": "node",
"args": ["/path/to/meet-rupert-mcp/dist/index.js"],
"env": {
"MEETRUPERT_EMAIL": "service-user@yourdomain.com",
"MEETRUPERT_PASSWORD": "…",
"MEETRUPERT_BASE_URL": "https://app.meetrupert.com/api"
}
}
}
}The env block can be omitted if a .env file sits next to the server (env is
loaded relative to the built file, not the host's working directory). You can
also add it interactively via /mcp in Claude Code.
npm run typecheck # tsc --noEmit
npm run build # tsup → dist/
npm run dev # rebuild + restart on change
npm start # node dist/index.js
npm test # vitest — Tiptap converters, SSE parser, attachmentsThe attachment tests cover round-trip sha256 integrity, the size cap on every
input path (including a body that only breaches it partway through streaming),
extension/magic-byte mismatch, path traversal via .. and via symlink, SSRF
against private and metadata addresses, cross-tenant reads, and a document
referencing an unknown attachment:// id failing without saving.
Ask the Meet Rupert AI a natural-language question. It runs Retrieval-Augmented Generation over the PUBLISHED documents in the knowledgebase and returns a synthesised answer plus the source documents it used (with their documentIds, which you can pass to read_document). This is a one-shot question with no memory of previous calls — use create_chat_thread + ask_in_thread for a multi-turn conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | A natural-language question to answer from the knowledgebase (max 500 chars). | |
| categoryIds | No | Optional list of category UUIDs (from list_categories). On create/update, tags the document. On ask tools, restricts retrieval to these categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: RAG over PUBLISHED documents (excluding drafts), returns synthesized answer plus source IDs, and is stateless with no memory of prior calls. It adds meaningful context beyond the schema, though it does not mention error handling or authentication requirements.
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 two focused sentences, front-loaded with the core action and including critical distinctions (published docs, one-shot, source IDs). Every sentence earns its place with no filler.
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 no output schema, the description sufficiently explains the return content (synthesized answer + source documents with documentIds) and the tool's scope (published documents, one-shot). It could mention edge cases like zero sources or filter behavior, but the description is complete enough for a typical QA use case.
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 100% and both parameters (question and categoryIds) are already well described in the input schema. The tool description adds little extra semantic value beyond what the schema provides, but the schema itself is sufficient.
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's purpose: asking a natural-language question to the Meet Rupert AI via RAG, returning a synthesized answer with source documents. It distinguishes itself from siblings by explicitly contrasting with ask_in_thread for multi-turn conversation.
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 says when to use this tool (one-shot question) and provides a direct alternative: 'use create_chat_thread + ask_in_thread for a multi-turn conversation.' This gives the agent clear decision criteria, and it even hints at follow-up via read_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a question within an existing conversation thread. The AI answers with the thread's prior messages as context (so follow-ups like "and what about X?" work), running RAG over the published knowledgebase. Returns the answer plus source documents. Both your question and the answer are saved to the thread.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The next message/question in the conversation (max 4000 chars). | |
| threadId | Yes | The thread UUID from create_chat_thread or list_chat_threads. | |
| categoryIds | No | Optional list of category UUIDs (from list_categories). On create/update, tags the document. On ask tools, restricts retrieval to these categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the side effect ('Both your question and the answer are saved to the thread'), clarifies retrieval behavior ('running RAG over the published knowledgebase'), and notes the return value ('Returns the answer plus source documents'). This is good but not exhaustive (e.g., no mention of rate limits or permission requirements).
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, followed by behavior and return value. Every sentence earns its place; no padding.
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 tool with no output schema, the description adequately explains the return value, usage context, and side effects. It is complete enough for an agent to select and invoke the tool correctly, given sibling tools.
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 100%, so the baseline is 3. The description adds some context (e.g., categoryIds restrict retrieval during RAG), but the schema already explains parameter meanings. The description does not substantially enrich the parameter semantics 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 tool's function: 'Ask a question within an existing conversation thread.' It distinguishes itself from siblings by emphasizing thread context ('prior messages as context') and follow-up capability, differentiating from ask_ai or search_documents.
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?
Usage context is implied clearly: use when an existing thread is held and contextual follow-ups are needed ('follow-ups like "and what about X?" work'). It does not explicitly name alternatives or exclusions, but the context is enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload an image so it can be embedded in a Meet Rupert document. PASS A FILE PATH OR AN HTTPS URL — NOT THE IMAGE DATA. The server reads the bytes itself; there is no base64 or inline-content parameter and you must not attempt to supply one. This is because a large payload placed in a tool-call argument gets silently truncated in transit (an 18,880-byte payload arrived as 7,312 bytes in testing, corrupting the file with no error raised), which rules out essentially every real screenshot. Letting the server read the file makes the returned contentLength and sha256 facts about the file itself, so you can verify them against the source. Accepts image/png, image/jpeg, image/webp and image/gif only, up to 10 MB — the type is determined from the file's magic bytes, not its extension. SVG and non-image files (PDF, .docx, plain text) cannot be attached: the platform has no storage for them. Returns an attachmentId and a ready-to-use markdownRef like  — put that in the content of create_document or update_document to place the image.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to an image file on a filesystem this SERVER can read. The server opens and reads the file itself — do not read the file yourself and do not pass its contents. Must be inside an operator-configured allowlist (MEETRUPERT_ATTACHMENT_DIRS); if none is configured, path is refused and you should use source_url instead. | |
| caption | No | Alt text / caption for the image, used in the returned markdownRef. Worth setting: it is what a reader sees if the image fails to load. | |
| source_url | No | An https:// URL the server fetches itself. HTTP is refused, redirects are not followed, and private/loopback/link-local/cloud-metadata addresses are blocked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals the critical truncation bug with large payloads, explains that the server reads the file itself, notes type detection via magic bytes, and describes security restrictions (HTTP refused, redirects not followed, private addresses blocked). This is exemplary transparency.
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 appropriately sized for the tool's complexity, with every sentence providing critical information. It is front-loaded with the most important instruction (path or URL, not data) and logically flows through constraints, rationale, and return value usage.
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 tool with no output schema, the description covers return values (attachmentId, markdownRef), usage with downstream tools, accepted formats, size limits, and failure cases. It provides complete operational context without relying on structured annotations.
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?
Although schema coverage is 100%, the description adds substantial value beyond schema: it explicitly warns not to pass image data, explains the truncation rationale, and clarifies that contentLength and sha256 are facts about the source file. The caption is given extra context about its use in fallback display, enriching the schema's basic description.
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 uploads an image for embedding in a Meet Rupert document, with a specific verb and resource. It distinguishes itself from sibling attachment tools (list, download, delete) and is unambiguous about its core function.
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 guidance: pass a file path or HTTPS URL, not image data; explains accepted types and size limit; and states that non-image files cannot be attached. Clearly indicates how the returned markdownRef is used with create_document/update_document, giving practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new conversation thread for multi-turn Q&A with the Meet Rupert AI. Returns a threadId to pass to ask_in_thread. The thread's title is generated by the platform. Use this when follow-up questions need to remember earlier context; for a single standalone question use ask_ai.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns a threadId for use with ask_in_thread, and that the title is auto-generated by the platform. This covers the key behavioral output and platform behavior, though it could mention persistence or side effects. Still, for a simple 0-parameter create tool, this is solid.
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 two concise sentences, front-loaded with the main action, then return value, platform behavior, and usage guidance. No fluff or repetition, every sentence earns its place.
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 (no params, no output schema), the description is complete: it explains what it does, what it returns, how the title works, and when to use it versus the alternative ask_ai. It also references ask_in_thread, providing seamless context for the next step in the workflow.
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?
There are zero parameters, and the input schema is empty, so schema coverage is trivially 100%. The description adds no parameter-specific information because there are no parameters. Per the rubric baseline for 0 params, a score of 4 is appropriate.
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's function: 'Create a new conversation thread for multi-turn Q&A with the Meet Rupert AI.' It uses a specific verb (create) and resource (conversation thread), and distinguishes itself from sibling tools like ask_ai and ask_in_thread by explaining it creates the thread rather than answering directly.
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 says when to use this tool: 'Use this when follow-up questions need to remember earlier context; for a single standalone question use ask_ai.' This provides clear context and names an alternative, which is exactly what usage guidelines should offer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new document in the Meet Rupert knowledgebase. Provide the body as Markdown; it is converted to the platform's rich-text format. By default the document is saved as a DRAFT (not searchable by the AI) so a human can review it before publishing — pass published:true to make it live immediately. Returns the new document's id. To embed images, upload each one with create_attachment (which takes a file path or an https:// URL — never image data) and place the markdownRef it returns in content. Every attachment:// reference is verified before saving: if one is unknown or belongs to another workspace the save fails naming the offending id, rather than storing a broken image.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | The document title (1–255 characters). | |
| content | Yes | The document body as Markdown (headings, lists, bold/italic, code blocks are supported). To include an image, call create_attachment first — passing it a file path or URL — and put the markdownRef it returns on its own line here. Never paste image data, base64 or a data: URI into this field; it will not render and large values are silently truncated in transit. | |
| published | No | If true, the document is published and becomes searchable by the AI. Defaults to false (saved as a draft for a human to review and publish). | |
| categoryIds | No | Optional list of category UUIDs (from list_categories). On create/update, tags the document. On ask tools, restricts retrieval to these categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so admirably. It discloses default draft behavior (not searchable), Markdown-to-rich-text conversion, return of the document id, and attachment verification failure modes. This is substantial and non-obvious behavior.
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 six sentences, dense yet perfectly organized: purpose, conversion behavior, draft default, return value, image embedding, and edge-case failure. Every sentence earns its place with no waste or 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 lacking an output schema and annotations, the description covers return value, failure behavior, default state, and interactions with sibling tools. It gives an agent everything needed to invoke the tool correctly and safely.
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 descriptions already cover all 4 parameters at 100%, setting a baseline of 3. The description adds extra context beyond the schema by explaining rich-text conversion and attachment reference verification, but most parameter semantics remain in the schema. A 4 is appropriate for the added 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?
The description opens with 'Create a new document in the Meet Rupert knowledgebase,' which is a specific verb+resource that clearly identifies the tool's function. It distinguishes itself from siblings like update_document and create_attachment by focusing on new document creation.
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?
It provides explicit when-to-use guidance: explaining the draft/published default, directing users to create_attachment for images, and warning against pasting image data. This goes beyond generic context and gives actionable alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an image from a document by deleting its reference from the document body. IMPORTANT: this does NOT delete the stored image itself — the Meet Rupert platform exposes no endpoint for that, so the object remains in storage and stays reachable by anyone holding a signed URL. Treat this as 'unlink from document', not 'delete'. Genuine deletion needs a platform change; do not tell a user their file has been erased.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | The document to remove the reference from (get it from list_attachments or search_documents). | |
| attachmentId | Yes | The attachment's id, from list_attachments or create_attachment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the stored image remains in storage and accessible via signed URL, and that no deletion endpoint exists. This goes beyond the basic action to explain real-world consequences, security implications, and how to communicate with users. No annotations were provided, so the description carries the full burden and excels.
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 compact yet information-dense. Every sentence adds value: the core action, the critical caveat about not deleting the stored image, the security note about signed URLs, and explicit user-communication guidance. The structure is front-loaded with the action and then elaborates on important nuances.
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 misleading tool name and the absence of annotations or output schema, the description provides all necessary context: what is actually deleted, what remains, why deletion is impossible, and how to handle user expectations. It is fully self-contained for safe and correct usage.
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 already provides 100% coverage of the two parameters with descriptions (documentId and attachmentId). The tool description adds no additional parameter-level detail beyond the conceptual 'deleting its reference' phrase, which does not enhance the schema's clarity. Baseline 3 is appropriate.
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's function: removing a reference from a document body. It distinguishes itself from actual deletion by emphasizing it only unlinks, which is critical given the tool's name. This specific verb+resource combination makes the purpose unambiguous.
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 warns that this is 'unlink from document', not 'delete', and advises against telling users their file has been erased. This provides strong guidance on when to use the tool and what not to claim. However, it does not explicitly name alternative tools or scenarios where one would choose this over a different operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a stored attachment, either by writing it to a file path the server can reach (destPath) or by returning a short-lived signed URL (signedUrl:true). Returns the byte length and sha256 of what was written so you can verify it against the original. Image bytes are never returned inline — that is the same truncation hazard create_attachment exists to avoid, and a path plus a checksum is what verifying integrity actually needs.
| Name | Required | Description | Default |
|---|---|---|---|
| destPath | No | Absolute path to write the image to. Must be inside the server's configured allowlist (MEETRUPERT_ATTACHMENT_DIRS). Omit this and pass signedUrl:true instead if you only need a link. | |
| signedUrl | No | If true, return a short-lived URL instead of writing a file. The URL expires in minutes and is scoped to this workspace. | |
| attachmentId | Yes | The attachment's id, as returned by create_attachment or list_attachments (looks like `3f8a1c92-….png`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that image bytes are never returned inline, explains the rationale (truncation hazard), and describes the verification output (byte length and sha256). This goes well beyond the schema and gives the agent a solid understanding of the tool's behavior and limitations.
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 compact (three sentences) and front-loads the core action. Every sentence serves a purpose: the first states the two modes, the second explains return values, and the third provides an important behavioral caveat. No wasted 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?
Given the tool's moderate complexity (two modes, no output schema, no annotations), the description is exceptionally complete. It covers what the tool does, how to use it, what it returns, and a key limitation. The schema handles parameter details, so the description focuses on the conceptual and behavioral context, making it fully adequate for correct invocation.
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 already provides 100% coverage of the three parameters, so the baseline is 3. However, the description adds meaningful context: it clarifies the trade-off between destPath and signedUrl and reinforces that inline bytes are not returned, which helps the agent choose the right parameter combination. This extra semantics justifies a 4.
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's purpose with a specific verb and resource: 'Download a stored attachment'. It also distinguishes between the two modes (writing to a file path or generating a signed URL) and differentiates the tool from siblings like create_attachment and delete_attachment by focusing on retrieval.
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 when to use each parameter (destPath vs. signedUrl) and implicitly warns against trying to get inline bytes, referencing the 'truncation hazard create_attachment exists to avoid'. This provides clear context and even names an alternative tool and why it's not suitable for downloading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the images embedded in a Meet Rupert document, with each one's attachmentId, alt text and whether it still resolves in storage. Use this to find the id of an image you want to download or remove, or to check a document for broken images.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | The document's UUID (as returned by search_documents). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the returned fields and a specific behavioral nuance: 'whether it still resolves in storage.' It implies a read-only operation via 'List' but does not explicitly state permissions or side effects. Still, for a listing tool, this is reasonably transparent.
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 two sentences, front-loaded with the core action and result, then providing usage guidance. Every word earns its place with no fluff or 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?
The tool is simple with one parameter and no output schema. The description provides enough return-value information (attachmentId, alt text, resolution status) and use cases to be actionable. It could mention pagination or whether all images are listed, but for a straightforward listing tool this is adequate.
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 covers the single parameter fully: documentId is described as 'The document's UUID (as returned by search_documents).' The description adds no extra parameter semantics beyond referring to 'a Meet Rupert document,' so the baseline of 3 applies given 100% schema coverage.
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's function: 'List the images embedded in a Meet Rupert document' with specific detail on what is returned (attachmentId, alt text, resolution status). This distinguishes it from sibling attachment tools like create_attachment, download_attachment, and delete_attachment.
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 use cases: 'Use this to find the id of an image you want to download or remove, or to check a document for broken images.' It gives clear context, but does not explicitly name alternative tools or state when not to use it, though the use cases imply alternatives like download_attachment and delete_attachment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the document categories in the knowledgebase, with their UUIDs and document counts. Use these ids for the categoryIds parameter when creating/updating documents or when scoping ask_ai retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return type (UUIDs and document counts), which is useful. However, it does not explicitly state whether this is a read-only operation, whether authentication is required, or if pagination applies. For a simple list operation, this is acceptable but not deeply transparent.
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 consists of two concise sentences. The first sentence front-loads the tool's core function and output, and the second provides practical usage guidance. There is no redundant or irrelevant content.
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 zero-parameter tool with no output schema, the description is complete. It specifies what the tool returns (UUIDs and document counts) and how to use the returned IDs in related operations. An agent has everything needed to select and invoke this tool appropriately.
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 tool has zero parameters, so there are no parameter details to explain. Schema coverage is trivially 100%. The description still adds value by referencing the categoryIds parameter used in other tools, helping the agent connect this tool's output to other operations. Baseline for 0 parameters is 4.
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 clearly states the specific action: 'List the document categories in the knowledgebase, with their UUIDs and document counts.' This distinguishes the tool from siblings like search_documents or read_document, which handle different resources. The scope is unambiguous and the output characteristics are mentioned.
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 directs when to use the tool: 'Use these ids for the categoryIds parameter when creating/updating documents or when scoping ask_ai retrieval.' This provides clear context for why an agent would call this tool. It doesn't name alternatives because no sibling provides category listing, so explicit exclusions are unnecessary. Slightly less than 5 because it doesn't explicitly state 'use this instead of X.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your recent Meet Rupert conversation threads with their titles and threadIds, so you can resume one with ask_in_thread. Returns the most recent threads first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It specifies that threads are 'recent' and owned by the user ('your'), includes return content (titles, threadIds), and notes ordering ('Returns the most recent threads first'). It does not mention pagination or limits, but for a simple read-only list, this is reasonably transparent.
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 extremely concise: two short sentences that front-load the core purpose and then add the ordering detail. Every word earns its place, with no redundant phrasing.
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 low complexity (zero parameters, no output schema), the description is complete. It fully explains what the tool returns, for whom, and in what order, with no confusing gaps. A simple list tool needs no further elaboration.
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 tool has zero parameters, so according to the rubric baseline is 4. The description cannot add parameter-level detail, but it documents the output semantics (titles, threadIds, ordering) that would otherwise be expected from parameters.
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 uses a specific verb+resource ('List your recent Meet Rupert conversation threads') and clearly states what is returned (titles and threadIds). It distinguishes itself from siblings like create_chat_thread and ask_in_thread by explicitly mentioning resuming with ask_in_thread.
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?
It provides clear usage context by stating 'so you can resume one with ask_in_thread', directly linking this tool to its intended follow-up. However, it does not explicitly mention when not to use it (e.g., for creating new threads) or name alternative tools beyond the implicit reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single Meet Rupert document by its UUID. Returns the title, metadata, and the document body converted to Markdown for easy reading. Get the documentId from search_documents or from an ask_ai source reference. Embedded images come back as  references. Those are stable and can be passed straight back to update_document — keep them in the body to preserve the images, and use list_attachments or download_attachment if you need the files themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | The document's UUID (as returned by search_documents). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description thoroughly discloses behavior: the body is converted to Markdown, images appear as stable references that can be passed to update_document, and it clarifies what is not included (actual files). This goes beyond the simple read action and provides actionable insights.
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 three sentences but packs all essential information: purpose, return format, source of documentId, and image handling guidance. There is no fluff or redundancy, and the structure puts the core action first.
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?
With one parameter and no output schema, the description fully covers what an agent needs: how to get the ID, what the return contains, and how to handle embedded image references. It also connects to related tools, making it complete for the tool's complexity.
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 100% with a clear parameter description, so the baseline is 3. The tool description adds value by mentioning an additional source for the documentId (ask_ai source reference) beyond search_documents, and by explaining the UUID format in context. This slight extension over the schema warrants a 4.
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 'Read a single Meet Rupert document by its UUID' with a specific verb and resource, and distinguishes from sibling tools like search_documents (search) and update_document (modify). It also specifies what is returned: title, metadata, and body as Markdown.
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 context on when to use this tool: 'Get the documentId from search_documents or from an ask_ai source reference.' It also differentiates from attachment tools by stating to use list_attachments or download_attachment for files. However, it does not explicitly state situations where this tool should not be used, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Meet Rupert knowledgebase for documents by title. Returns a paginated list of matching documents with their UUIDs, titles, draft status, categories and last-updated dates. Use the returned id with read_document to fetch full content. This is a title/metadata search — to ask a natural-language question answered from document content, use ask_ai instead.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1 (default 1). | |
| query | No | Substring to match against document titles. Omit to list all documents. | |
| pageSize | No | Results per page, 1–100 (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return fields (UUIDs, titles, draft status, categories, last-updated dates), pagination, and the fact that it matches on title/metadata, not content. However, it omits potential details like case sensitivity, ordering, or inclusion of drafts, which are not fully disclosed.
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 concise sentences deliver purpose, return details, and usage guidance without redundancy. The most critical information (title-based search) is front-loaded, and every sentence earns its place.
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?
Without an output schema, the description enumerates return fields and links to read_document, which aids programmatic use. It lacks details about the response envelope (e.g., total counts, nested structure), but given the moderate complexity and strong chaining hints, it is reasonably 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?
Schema coverage is 100% for all three parameters, each with clear descriptions. The tool description adds context about pagination and linking to read_document, but does not meaningfully enhance the parameter semantics beyond what the schema already documents, so baseline 3 is appropriate.
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 searches the Meet Rupert knowledgebase by title, with specific verb and resource. It also immediately distinguishes itself from ask_ai, which queries document content, preventing confusion with sibling tools.
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 guidance is provided: it states this is a title/metadata search, and directs agents to use ask_ai for natural-language content queries. It also recommends using the returned id with read_document, suggesting a clear workflow and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing Meet Rupert document. Any field you omit is left unchanged — pass only what you want to change. content (Markdown) replaces the entire document body, so read_document first if you're making a partial edit. Each update snapshots a new version and re-indexes the document for AI search. Returns the updated document's id and state. Because content replaces the whole body, any attachment:// ref you drop from it removes that image from the document — preserve the refs read_document gave you. Add new images via create_attachment, never by pasting image data.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New title. Omit to keep the current title. | |
| content | No | New body as Markdown, replacing the existing content. Omit to keep the current content. (Read the document first if you intend to make a partial edit — this replaces the whole body.) read_document returns existing images as `` refs; keep those refs in the text you send back or the images will be removed from the document. To add a new image, call create_attachment and insert its markdownRef — never paste image data or base64 here. | |
| published | No | Set true to publish (make AI-searchable) or false to unpublish (draft). Omit to keep the document's current published/draft state. | |
| documentId | Yes | The document's UUID (as returned by search_documents). | |
| categoryIds | No | Optional list of category UUIDs (from list_categories). On create/update, tags the document. On ask tools, restricts retrieval to these categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses that content replaces the whole body, that dropping attachment:// refs removes images, that each update snapshots a new version and re-indexes for AI search, and it states the return value (updated id and state). This surfaces important non-obvious behaviors and 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?
The description is about 100 words, which is justified given the tool's complexity (content replacement, attachment refs, re-indexing). It is front-loaded with the core purpose and then addresses critical caveats. Every sentence adds value, though it could be slightly tightened without losing meaning.
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 5 parameters, no output schema, and no annotations, the description is remarkably complete. It covers partial update behavior, content replacement risks, attachment handling, side effects (versioning, re-indexing), and the return shape. It also references sibling tools (read_document, create_attachment) appropriately, providing the necessary context for safe invocation.
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 input schema has 100% field-level descriptions and already covers omit-to-keep semantics, content replacement, and attachment refs. The tool description reinforces these but adds little beyond the schema. It offers a global 'Any field you omit is left unchanged' statement, but that is already individually expressed in each parameter. Baseline 3 is appropriate because the schema does the heavy lifting.
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 opens with 'Edit an existing Meet Rupert document,' which is a specific verb+resource ('edit' + 'existing document') that clearly distinguishes it from creation (create_document) and other siblings like read_document or ask_ai. It also conveys the update scope by emphasizing partial edits.
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 gives explicit usage guidance: 'pass only what you want to change,' and calls out prerequisites/alternatives such as 'read_document first if you're making a partial edit' and 'Add new images via create_attachment, never by pasting image data.' It also clarifies that re-indexing occurs, affecting AI search, which helps decide when to use the tool.
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.0ask_aiask_in_threadcreate_attachmentcreate_chat_threadcreate_documentdelete_attachmentdownload_attachmentlist_attachmentslist_categorieslist_chat_threadsread_documentsearch_documentsupdate_documentScored across 13 tools
Each tool targets a distinct resource and action, with clear separation between document CRUD, attachment management, and AI chat. Descriptions explicitly clarify potential overlaps like search_documents vs ask_ai and ask_ai vs ask_in_thread, so an agent should not confuse them.
All tool names follow a consistent verb_noun pattern (read_document, create_attachment, list_categories), with AI queries uniformly using ask_* (ask_ai, ask_in_thread). There are no mixed conventions or vague verbs.
13 tools cover documents, attachments, and chat threads without unnecessary bloat. The scope is well-defined for a knowledgebase server, and each tool has a clear role in the workflow.
The document lifecycle is missing delete_document, which is a notable gap given create, read, and update are all present. Additionally, search_documents only searches by title, so there is no straightforward way to list all documents. Attachment deletion is intentionally not a true delete, but that is explicitly documented as a platform limitation.
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Search your knowledge bases from any AI assistant using hybrid RAG.
