Server Quality Checklist

Tool Scores

• list_attachmentsA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• ask_in_threadA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• list_categoriesA
  4.3/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• ask_aiA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• search_documentsA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• delete_attachmentA
  4.5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• list_chat_threadsA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• update_documentA
  4.6/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• create_chat_threadA
  4.7/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• read_documentA
  4.7/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• create_documentA
  4.9/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• download_attachmentA
  4.9/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• create_attachmentA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.