Server Quality Checklist

Tool Scores

• get_pdf_infoA
  3.8/5.0
  Behavior2/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 mentions the loading prerequisite but does not explicitly state that the operation is read-only, has no side effects, or explain behavior with invalid document IDs. The tone suggests a getter, but this is not made explicit.

  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 purpose, and contains zero fluff. The prerequisite is stated efficiently without repetition. It is an excellent example of conciseness.

  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 the tool's simplicity (1 parameter, output schema exists), the description covers the essential context: what it does and the necessary prerequisite. However, it could be slightly more complete by contrasting with list_loaded_pdfs (e.g., 'Use for a single document, not enumeration') to help the agent choose among siblings. No output schema explanation is needed since one exists.

  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 description for document_id is already clear ('Identifier of the loaded document'), and the tool description enhances it by clarifying that the document must be loaded first using load_pdf. This adds contextual meaning to the parameter, helping the agent understand valid input values beyond the raw 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: 'Get basic information about a loaded PDF document.' The verb 'get' with resource 'loaded PDF document' is specific and distinct from sibling tools like extract_text_from_pdf or list_loaded_pdfs. It immediately sets expectations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear prerequisite: 'The document must be loaded first using load_pdf.' This indicates when to use the tool, but it does not explicitly contrast with alternatives or mention when not to use it. The guidance is present but minimal compared to examples like get_calls.

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

• extract_text_from_pdfA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does disclose a key prerequisite (the document must be loaded), but it does not explicitly state that this is a read-only operation, nor does it describe behavior on invalid document IDs or large documents. The prerequisite is valuable, but more behavioral context would be expected given the lack of annotations.

  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 short sentences that are front-loaded with the core action and followed by the key prerequisite. Every sentence earns its place, making it highly concise and easy to scan.

  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 description covers the essential prerequisite and the schema fully documents all parameters. An output schema exists, so return values do not require explanation. However, the description does not mention alternative tools or potential error conditions, leaving some contextual gaps for an agent choosing the right tool.

  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%, with all three parameters (format, document_id, page_number) having clear descriptions. The tool description adds no parameter-specific information beyond the schema, so it meets the baseline expectation but does not exceed it.

  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: 'Extract text from a loaded PDF document.' It uses a specific verb and resource, and the prerequisite of a loaded document adds precision. This distinguishes it from sibling tools like load_pdf, search_text_in_pdf, and redact_by_coordinates, which have different purposes.

  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 states a necessary precondition: 'The document must be loaded first using load_pdf.' This gives clear sequential usage context. However, it does not discuss when to prefer this tool over alternatives like search_text_in_pdf or get_pdf_info, so it falls short of a full usage guideline.

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

• redact_by_coordinatesA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description must disclose behavioral traits. It does mention in-memory modification and the need to save, which is useful, but omits the irreversible nature of redaction once saved and does not specify coordinate system semantics or side effects beyond persistence. This is a moderate disclosure level.

  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: a clear purpose statement followed by two essential workflow constraints. Every sentence adds value, no filler or redundant content.

  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 description covers the required prerequisites and persistence workflow (load first, in-memory, save to disk). The presence of an output schema means return values need not be explained. It lacks details about coordinate system semantics, but overall it provides enough context for correct invocation in a multi-step PDF workflow.

  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% description coverage for all parameters, including detailed descriptions for redactions, fill_color, and overlay_text. The tool description adds little beyond the phrase 'by coordinates' and does not clarify coordinate origin or units, but the baseline of 3 is appropriate because the schema carries the semantic load.

  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 explicitly states the tool redacts specific areas of a loaded PDF by coordinates, which is a distinct verb+resource+method combination. It also differentiates from sibling redaction tools that target text or images by naming the coordinate-based approach.

  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 gives clear prerequisites and workflow: the document must be loaded first, modifications are in-memory, and save_pdf is required to persist changes. It does not explicitly name alternatives like redact_text_by_search or redact_images_in_pdf, but the coordinate-based scope is implied.

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

• redact_text_by_searchA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It discloses that modifications are in-memory and require save_pdf, which is valuable context. However, it does not mention irreversibility, appearance of redaction, or whether text is physically removed, leaving gaps in 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 three sentences, front-loaded with the core action, followed by essential workflow notes. No redundant or unnecessary information is present; 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?

  The tool is part of a clear workflow (load, redact, save), and the description covers both prerequisite and saving steps. An output schema exists, so return values need not be explained. It lacks only explicit guidance on choosing this tool over coordinate-based redaction, but overall is sufficiently 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter has its own description in the schema. The tool description adds little beyond clarifying that search_strings are 'specified text strings' and the document must be loaded, but the schema already handles parameter meaning effectively.

  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 redacts all occurrences of specified text strings in a loaded PDF, using a specific verb and resource. It distinguishes itself from sibling tools like redact_by_coordinates and redact_images by focusing on text-based redaction.

  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 clear workflow context: the document must be loaded first using load_pdf, and changes must be saved via save_pdf. While it does not explicitly mention alternatives like redact_by_coordinates, the prerequisites and persistence steps are clearly communicated.

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

• save_pdfA
  4/5.0
  Behavior3/5

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

  Since no annotations are provided, the description must carry the behavioral burden. It does disclose a key behavior: the document remains in memory and can be modified after saving. But it omits other potentially relevant details such as whether the file will be overwritten, permission requirements, or error behaviors. This adds some transparency but not a rich behavioral picture.

  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, with the primary action front-loaded and the second sentence providing valuable behavioral context. There is no redundancy or filler, making it concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a narrowly scoped save operation with two well-documented parameters and an output schema, the description covers the essential information for selection and invocation. It could mention overwrite behavior or error handling, but such details are not critical for the tool's basic use. Overall, it is sufficiently 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?

  The input schema already fully documents both parameters with clear descriptions (document_id and output_path), and schema coverage is 100%. The description adds no additional parameter-level information, so the baseline score of 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 uses a specific verb 'Save' with the resource 'in-memory PDF document' and destination 'disk', clearly distinguishing it from sibling tools like load_pdf, close_pdf, or redact functions. The phrase 'in-memory' also clarifies that the document must already be loaded, which is a distinct context.

  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 clearly implies when to use the tool: when you have an in-memory PDF document and want to persist it to disk. It notes that the document remains loaded after saving, which implicitly contrasts with close_pdf. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

• verify_redactionsA
  4/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 of behavioral disclosure. It does disclose the prerequisite and the comparative nature of the operation, but it does not mention whether the tool is read-only, what happens if documents are not loaded, or how search_strings are used beyond the schema description. This leaves some behavioral gaps.

  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 primary action and a clear prerequisite. No wasted words; every sentence earns its place. It is appropriately sized for the tool's simplicity.

  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?

  With a complete input schema and an output schema present, the description is sufficiently complete for the tool's moderate complexity. It covers the purpose and the prerequisite. The only minor gap is not explicitly tying search_strings to the comparison, but the schema's description of that parameter fills the gap.

  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?

  All parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds the contextual note that documents must be loaded first, but it does not add extra meaning to the individual parameters beyond what the schema already provides. The search_strings parameter is only explained in the schema, which is adequate.

  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 ('Verify') and resource ('redactions') and explains the method ('comparing two loaded PDF documents'). It clearly distinguishes the tool from siblings like redact_text_by_search or search_text_in_pdf, and the prerequisite of loading documents first is stated, making 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 states that both documents must be loaded first using load_pdf, providing a clear precondition for use. It implies usage after redaction ('verify that redactions were applied correctly'). It does not explicitly list alternatives or when-not-to-use, but the context is sufficient for a well-defined workflow.

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

• redact_images_in_pdfA
  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 burden of disclosing side effects. It clearly states that modifications are in-memory and require an explicit save to persist, which is essential for a mutating operation. It does not detail the irreversible nature of redaction after saving, but the save step implies this.

  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 long, front-loads the primary purpose, and provides necessary workflow context without any redundant information. 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?

  Given the large sibling set and the tool's complexity, the description covers the necessary context: how to load, modify, and save. It does not explain the full effect of redaction (e.g., underlying content is destroyed), but with a detailed schema and output schema present, 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?

  Schema descriptions cover 100% of the parameters, so the baseline is 3. The description does not add additional semantic details about parameters beyond what the schema already provides, but it does not need to.

  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 ('Redact all images in specified pages') with a specific verb and resource, and differentiates from sibling redaction tools by focusing on images. The distinction from redact_text_by_search and redact_by_coordinates is evident from the purpose.

  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 clear workflow guidance: the document must be loaded via load_pdf first, and changes are saved with save_pdf. It does not explicitly name alternatives, but the tool's purpose and sibling context make the appropriate use cases clear.

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

• search_text_in_pdfA
  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 full burden. It discloses that the tool searches for text and returns locations, and notes the dependency on a prior load_pdf call. This goes beyond the schema by explaining the output content and a state requirement, though it could explicitly state non-destructive 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 two sentences, front-loaded with the core action, and every sentence adds value. No wasted words.

  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 the presence of an output schema and full parameter descriptions, the description only needs to cover the tool's main behavior and prerequisites. It does that effectively, making the tool usable without missing critical context. A small gap is the lack of error-handling behavior (e.g., invalid document_id), but that is not essential.

  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%, with each parameter having a description. The tool description does not add parameter-specific meanings beyond what is already in the schema. According to the rubric, a baseline of 3 is appropriate when the schema provides full 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 with a specific verb ('Search') and resource ('loaded PDF document'), and specifies the output ('all occurrences with their locations'). This distinguishes it from sibling tools like extract_text_from_pdf or redact_text_by_search.

  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 a clear prerequisite: 'The document must be loaded first using load_pdf.' This gives context on when the tool can be used. It does not explicitly mention alternatives or when not to use it, but the purpose is unambiguous enough that no exclusions are necessary.

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

• close_pdfA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description discloses the destructive side effect: 'Any unsaved changes will be lost.' It also clarifies the scope ('in-memory') and the purpose of freeing memory, which is not present in the schema.

  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 sentences, each with a distinct purpose: state the action, give usage context, and warn about data loss. No fluff.

  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 simple close operation, the description covers the action, when to use it, and the key side effect. The output schema is provided separately, so the description needn't explain return values.

  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%; the description adds no additional explanation for document_id beyond the schema's 'Identifier of the loaded document.' Therefore, the baseline of 3 applies.

  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 'close and remove' and clearly identifies the resource ('in-memory PDF document'), distinguishing it from sibling tools like load_pdf or save_pdf. It also states the effect of freeing memory.

  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 states 'Use this to free up memory when you're done with a document,' providing a clear condition for when to invoke the tool. It also implicitly advises saving first with the warning about unsaved changes, but doesn't name alternative tools.

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

• load_pdfA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It states that the document remains in memory until saved or the session ends, which is key behavior beyond the obvious load action. However, it does not mention error handling or access requirements, so it's not a 5.

  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 composed of three concise, purposeful sentences: the core action, the prerequisite relationship, and the memory lifetime. Every sentence adds necessary information without 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?

  For a simple load tool, the description fully covers its role among the sibling tools, the mandatory usage prerequisite, and the in-memory lifetime. An output schema exists, so return values need not be described. The description is complete for its complexity.

  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 already provides descriptions for both pdf_path and document_id, achieving 100% schema description coverage. The tool description adds no parameter-specific details, so the baseline of 3 applies.

  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 'Load' and resource 'PDF file into memory', and explicitly states that all other PDF tools require this tool first, which clearly distinguishes it from siblings like extract_text_from_pdf and redact_text_by_search.

  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 gives clear context that this tool is a prerequisite for all other PDF tools, but it does not explicitly provide when-not-to-use guidance or name alternative tools, stopping short of a 5.

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

• list_loaded_pdfsA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It clarifies that the operation is non-mutating (listing) and specifies the return format (JSON string). It does not explicitly state 'does not modify documents,' but 'list' inherently implies read-only, and the description adds useful context.

  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-loads the main purpose, and includes relevant return information without any wasted words. Ideal conciseness.

  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 parameters) and the presence of an output schema, the description is complete. It covers the essential action and return type without needing to explain parameters or elaborate on return values.

  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 is nothing to explain. Per the rubric, a baseline of 4 is appropriate for a 0-parameter tool.

  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 states a specific action ('List') on a specific resource ('currently loaded PDF documents') with a scope ('in memory'). This unambiguously distinguishes it from sibling tools like load_pdf or save_pdf.

  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 context clearly implies when to use this tool (when you need to see which PDFs are loaded), but it does not explicitly mention alternatives or exclusions. Since the description is clear enough for a simple tool, it earns a 4.

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