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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds useful behavioral context beyond annotations: classes are grouped Monday through Sunday and include time, room, building, section, and courses without scheduled meetings. No contradiction with annotations.

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 purposeful sentences with no filler. The action and resource are front-loaded, output details follow compactly, and the term behavior is stated in one concise sentence. Every clause 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?

For a read-only tool with one optional parameter and no output schema, the description is complete. It explains what data is returned, how it is organized, the default term behavior, and the term override. An agent has enough information to select and invoke the tool correctly.

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 schema already documents the optional term code and its default behavior. The description adds a small nuance by saying 'registered past term,' which clarifies that the term must be one the student is registered in, but it does not substantially elevate meaning 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 states a specific verb and resource: 'Get the student's UPC weekly class schedule from their Banner registrations.' It also describes the returned grouping and fields, making the tool's purpose unmistakable. The explicit 'Banner' source separates it from the sibling campus_get_weekly_schedule.

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 clear context for when to use the optional term parameter: 'Uses the active term by default; pass term to consult a registered past term.' It does not explicitly name alternatives or exclusions, but the Banner-specific scope implies when this tool applies.

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

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

Description adds meaningful behavioral context beyond annotations: files are stored in a 'protected Campus download directory' and 'outputDir may be a relative subdirectory only'. This complements the readOnlyHint=false annotation by specifying the side effect location. It does not mention overwrite behavior or return values, but the key destination constraint is 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?

Two concise sentences, front-loaded with the main action, and every word earns its place ('protected Campus download directory' and 'relative subdirectory only' are essential constraints). No verbose or 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 5 parameters, full schema coverage, and no output schema, the description provides adequate context for invocation: it specifies source, destination, and a key parameter constraint. However, it lacks guidance on when to call this after blackboard_list_attachments and does not mention what the tool returns, leaving minor gaps.

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 covers all 5 parameters with descriptions (100% coverage), including details like 'Relative subdirectory inside ~/Downloads/campus-cli'. Description only reiterates the outputDir constraint without adding new semantic information beyond the schema, 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?

Description clearly states the action 'Download a file from a course content item' and destination 'protected Campus download directory'. This distinguishes it from sibling tools like blackboard_download_file_url by specifying the source (course content item) and target (protected download directory). Tool name reinforces attachment context.

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?

No explicit when-to-use or alternative tool guidance is provided. The description gives a clear context (downloading from course content) but does not contrast with siblings like blackboard_download_file_url or blackboard_download_feedback_file, leaving selection to the agent's inference from the name and description.

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

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

Annotations already mark it as non-read-only, non-idempotent, and open-world. The description adds the experimental status and version limitation, which is useful context. It does not disclose the download destination or potential side effects, but the schema parameters hint at that.

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 the purpose, and the second sentence provides the key workflow instruction. No wasted words; the experimental caveat is integrated naturally.

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 complexity (6 params, 4 required, no output schema), the description explains the crucial workflow dependency (blackboard_get_assignment_feedback) and the potential unavailability. It does not describe the return value or output path, but the schema covers the output parameters, making it sufficiently 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%, so the baseline is 3. The description adds extra meaning by explaining the provenance of fileId, attemptId, and columnId from blackboard_get_assignment_feedback, and notes the filename defaults to the name in feedbackFiles, which goes 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 downloads a feedback file attached to a graded attempt, identifies the exact source of the fileId, and distinguishes this from generic attachment/download tools by referencing the feedback workflow. The experimental note adds clarity about its reliability.

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 explicitly tells the agent to use the fileId from blackboard_get_assignment_feedback, establishing a clear usage context. However, it does not explicitly differentiate from sibling tools like blackboard_download_attachment, though the feedback-specific focus implies when to use it.

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

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

Annotations already disclose readOnlyHint=false and openWorldHint=true. The description adds the destination directory context, but lacks behavioral details such as overwrite behavior, download size limits, or authentication requirements. It provides some transparency beyond annotations but not rich context, earning a mid-range score.

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 a single, well-structured sentence that front-loads the action and key resource details. Every word earns its place, with no redundancy or irrelevant information.

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 relatively simple download operation, the description covers the core purpose adequately, supported by a complete schema and annotations. It lacks explicit mention of return values or error behavior, but those are not critical given the tool's simplicity. The absence of output schema is partially mitigated by the clarity of the action.

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% coverage with clear descriptions for all three parameters (url, filename, outputDir). The description does not add significant meaning beyond the schema; it only implies the destination directory, which the schema already covers via outputDir's description. Baseline of 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 uses the specific verb 'Download' and identifies a precise resource ('Blackboard bbcswebdav file') and destination ('protected Campus download directory'), which clearly distinguishes it from sibling download tools like blackboard_download_attachment and blackboard_download_feedback_file. The name itself ('download_file_url') reinforces the unique purpose.

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 no guidance on when to use this tool versus alternatives such as blackboard_download_attachment. It does not state prerequisites, exclusions, or specific scenarios, leaving the agent to infer usage solely from the schema and name.

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

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

With no annotations, the description carries the behavioral disclosure burden. It states the tool shows score, instructor comments, and feedback files for graded submissions, which is useful. However, it does not explicitly state it is read-only, nor does it clarify how feedback files are represented or whether ungraded submissions are omitted.

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 the key action and resource. No filler or redundant wording; every phrase adds value.

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 no output schema, the description gives a high-level summary of the return content (score, comments, feedback files) but lacks structural detail. It is adequate for a simple read tool but leaves ambiguity about the exact response format and relationship to other feedback-related 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?

The only parameter, courseId, is already fully described in the schema with a pattern and description. The tool description does not add additional meaning about the parameter's usage or role within the tool.

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 identifies the action (get), resource (assignment feedback/scores), and scope (all assignments in a course). It distinguishes itself from siblings like get_grades or download_feedback_file by combining feedback, scores, and attached files into one tool.

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 implies usage for retrieving professor feedback and scores, but it does not explicitly state when to prefer this over alternatives like blackboard_get_grades or blackboard_download_feedback_file. No exclusions or conditional guidance are provided.

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

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 states 'Get details' but does not disclose whether the operation is read-only, what 'details' includes, any authentication requirements, or potential errors. The description adds no behavioral transparency beyond the tool's name and basic purpose.

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 a single concise sentence, front-loaded with the action and resource, and provides an example. No filler or redundant information; every word 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?

The tool is simple with one parameter, no output schema, and no annotations. The description is minimally adequate but does not explain what 'details' means or what the return structure might be. Given the lack of output schema, the description should offer more context about the response, making it borderline but not severely lacking.

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% (courseId is fully described with pattern and example). The tool description repeats the same example '_529580_1' without adding new semantic value. Per rubric, baseline is 3 when schema covers parameters fully.

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: 'Get details of a specific course by its Blackboard ID'. The verb 'get' and resource 'course' are specific, and the phrase 'specific course' distinguishes it from siblings like blackboard_list_courses which retrieves multiple courses.

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 implies usage when you have a specific Blackboard course ID, but it does not explicitly state when to use this tool over alternatives or mention that list_courses should be used to obtain IDs. No exclusions or alternative references are provided, so it's only implied context.

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

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. It discloses that the tool reads a discussion and includes the topic/prompt only when Blackboard exposes it, and implicitly states it does not return student posts. However, it omits details like error behavior, authentication requirements, or what happens if the discussion ID is invalid. For a read operation, this is acceptable but not rich.

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 with zero filler. The core purpose and caveat are in the first sentence, and the routing to a sibling is in the second. Every word 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?

For a simple read operation with two well-documented parameters, the description covers the essential purpose and the key limitation (no student posts). It does not describe the return format or error handling, but given the tool's simplicity and the absence of an output schema, the description is sufficient for correct invocation. Slightly more detail on expected return could push it to a 5.

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 descriptions for both parameters are complete (100% coverage), including the source for discussionId (from blackboard_list_discussions). The tool description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline without enhancing it.

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 states a specific action (read) on a specific resource (one Ultra discussion), and explicitly differentiates from sibling tools by noting it includes the topic/prompt when exposed and directing to blackboard_list_discussion_messages for student posts. This makes the tool's 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 second sentence explicitly says 'Use blackboard_list_discussion_messages to read student posts,' which provides a clear when-not-to-use condition and names the alternative tool. This is a textbook example of routing guidance.

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

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 adds specific value by revealing that embedded Blackboard media (images, audio, video, files) are included in embeddedFiles and that supported media also appear as resource_link blocks. This is beyond what the schema conveys. It could mention the default limit behaviors or the hierarchical structure, but the core trait (media inclusion) is disclosed, and 'Read' implies a non-mutating operation.

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 with zero filler. The first sentence gives the core purpose, and the second adds a key behavioral detail (media handling). Information is front-loaded, and every word earns its place. This is a model of conciseness.

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 read tool with six parameters and no output schema, the description covers the essential purpose and one notable output detail (media blocks). It does not explicitly describe the return format's hierarchy (though 'thread' implies it) or mention error conditions, but the schema covers parameter limits and defaults. Given the absence of annotations and output schema, the description is reasonably complete, though a note about the response being a nested structure would push it to a 5.

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% – every parameter has a clear description (e.g., maxDepth, replyLimit, messageLimit, status). The description itself does not add new parameter-specific meaning; it only implicitly references the thread structure that these parameters control. Since the schema already documents each parameter, the description's omission does not harm clarity, but it also does not enhance parameter understanding.

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 a specific verb ('Read'), a resource ('an Ultra discussion as a thread'), and a defined scope (discussion topic, top-level posts, and replies). It also references embedded media, which distinguishes it from other sibling tools like blackboard_list_discussion_messages or blackboard_get_discussion. This makes the tool's function unambiguous without needing to inspect the schema.

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 implies the use case (retrieve a whole thread) but does not explicitly contrast with alternatives such as blackboard_list_discussion_messages or blackboard_get_discussion. It lacks concrete guidance on when to choose this tool over a flat-list or single-message tool. The context is clear enough for a simple read operation, but it would benefit from explicit 'use this when you need nested replies' language.

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

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 implies a read-only operation but discloses no additional behavioral context such as authentication needs, rate limits, return format, or side effects. The basic 'get' semantics are clear, but nothing beyond that.

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 a single, front-loaded sentence with no redundant words. It conveys the core purpose efficiently, though it is slightly under-specified rather than overly verbose.

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 simple tool with one well-defined parameter, the description covers the basic action but omits details about the return payload or potential errors. With no output schema, the description should compensate, and it does not fully do so, but the tool's low complexity keeps it minimally viable.

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 documents the lone parameter (courseId) with type, pattern, and description, yielding 100% coverage. The description adds nothing about the parameter, so the baseline score of 3 is appropriate per the rubric.

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 ('Get') and identifies the resource ('all grades') with clear scoping ('for the current student in a course'). This distinguishes it from siblings that deal with assignments or feedback, though it does not explicitly name alternative 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where a sibling like get_assignment_feedback or list_attempts would be more appropriate, nor any prerequisites or context for invoking it.

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

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

With no annotations provided, the description carries the full burden. It indicates a read-only action ('list') and adds a behavioral constraint ('recent'), but does not define what 'recent' means (time window, count, ordering) or disclose pagination/limits. It is transparent about being a read operation but leaves key behavioral details unstated.

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 a single, clear sentence that immediately conveys the tool's purpose. No wasted words; it is concise and front-loaded.

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 (one param, no output schema), the description is adequate but with gaps: it does not explain the meaning of 'recent', expected output format, or usage guidelines. It is not rich enough to fully compensate for missing annotations, but it is sufficient for a basic list tool.

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% (courseId described as 'Blackboard course ID' with pattern), so the schema already documents the parameter. The description adds no additional meaning about the parameter beyond 'for a course', which is already implicit. Baseline 3 applies.

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 'list' and a clear resource 'announcements' scoped to 'a course', which distinguishes it from sibling tools like list_assignments or list_contents. It is immediately obvious what the tool does.

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 implies usage ('list announcements for a course') but provides no explicit guidance on when to choose this tool over alternatives like list_contents or list_assignments, nor does it mention exclusions or prerequisites. It has clear context but lacks comparative guidance.

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

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

No annotations are provided, so the description must carry the behavioral burden. It does disclose a non-obvious behavior: it includes group assessments normally hidden from the student gradebook API and marks them with gradebookAccess: restricted. However, it does not mention whether the operation is read-only, any authentication requirements, or response structure beyond the listed fields, leaving some gaps.

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 with no filler. The primary purpose is stated upfront, and the second sentence adds a valuable edge case without unnecessary elaboration. Every word 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?

For a simple list operation with a single parameter and no output schema, the description adequately covers what is returned (due dates, scores, submission status) and the special inclusion of hidden group assessments. It is slightly incomplete in not mentioning pagination or limits, but this is a minor gap given the tool's simplicity.

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 only parameter, courseId, is fully described in the schema with a pattern and a human-readable description. The tool description adds no additional meaning or usage details about the parameter, so it does not exceed the baseline given the 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 states a specific action ('List') and resource ('assignments and tasks in a course') with clear output fields (due dates, scores, submission status). It also adds a distinguishing detail about including group assessments hidden from the gradebook API, which differentiates it from other list tools like blackboard_list_attempts or blackboard_get_grades.

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 implies usage for retrieving assignment/task data but does not explicitly state when to use it versus alternative tools such as blackboard_get_grades or blackboard_list_attempts. No exclusions or alternative routing are mentioned, leaving the agent to infer based on the name and fields.

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

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

With no annotations provided, the description carries the full behavioral burden. It does well by disclosing that images, audio, and video are returned as MCP resource_link blocks, while attachment metadata remains available as a download fallback. It also specifies which content item types are supported. It does not cover pagination, errors, or explicit read-only guarantees, but the disclosed behavior is substantial.

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 with no filler. The core purpose is front-loaded, and the additional behavioral details about media resource links and download fallback are concise and relevant.

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, has only two well-documented parameters, and no output schema. The description explains the input context, supported attachment types, and the return shape at a useful level. A few details like no-attachments behavior or authentication requirements are absent, but the description is otherwise sufficient for an agent to call the tool correctly.

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%, so the baseline is 3. The description adds relevant context by explaining that contentId refers to a course content item and can include embedded files, but it does not add meaningful format or syntax details beyond the schema descriptions for courseId and contentId.

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 names a specific verb and resource: 'List file attachments for a course content item.' It also clarifies the relevant content types (x-bb-file, embedded document/assignment HTML), which distinguishes it from sibling tools like blackboard_download_attachment or blackboard_list_contents.

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 implies when to use the tool by defining the input scope, but it does not explicitly contrast it with alternatives such as blackboard_download_attachment. The mention of 'download fallback' hints at a related workflow, but no explicit when-to-use vs when-not-to-use guidance is provided.

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

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

No annotations are provided, and the description does not disclose any behavioral details beyond the action itself, such as return format, pagination, or read-only nature. It is a minimal statement with no added context.

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 a single, clear sentence with no redundant information. It is concise and to the point.

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?

While the two parameters are fully described, the absence of an output schema and lack of any information about the returned structure or behavior leaves some gaps. For a simple list operation, it is adequate but not fully 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?

Both parameters have full schema descriptions, and the tool description does not add any additional meaning beyond what the schema already states. Baseline 3 is appropriate given the 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 action (List), the resource (submission attempts), and the scope (specific assignment/gradebook column). This distinguishes it from sibling tools like list_assignments or get_grades.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or comparison with sibling tools like list_assignments or get_grades.

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

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

With no annotations, the description carries the burden. It discloses that the tool lists content and that parentId navigates into subfolders. While it doesn't mention return format or pagination, the tool is a straightforward read operation with no side effects, so the disclosure is sufficient.

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 concise sentences: the first states the main purpose, the second explains navigation. No filler or redundant information.

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, and the description covers purpose and navigation. It doesn't detail what 'content items' include (e.g., files, folders, assignments), but this is a minor ambiguity given Blackboard's standard terminology and the presence of distinct 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 coverage is 100%, with both parameters well described. The description adds value by explicitly saying 'Use parentId to navigate into subfolders', which clarifies the parentId parameter's purpose beyond the schema 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 uses a specific verb ('List') and resource ('content items') with scope ('inside a course or folder'). It clearly distinguishes itself from sibling tools like list_courses, list_announcements, and list_people by focusing on course content structure.

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 clear usage context: when to list contents and how to navigate into subfolders using parentId. It does not explicitly mention alternatives or exclusions, but the guidance is adequate for the tool's simple navigational purpose.

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

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

No annotations are provided, so the description carries the full burden. The verb 'List' implicitly indicates a read-only operation, and the 'current student' qualifier adds scope context, but it does not disclose potential behaviors such as pagination, return field structure, or authentication requirements. It is neither misleading nor rich, so a 3 is appropriate.

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 a single, clear sentence with no unnecessary words or redundancy. It is front-loaded with the verb and resource, making it maximally concise.

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 largely complete. It states exactly what it does. However, it could hint at what fields the returned course objects contain, but this is not critical for a simple list tool.

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 the schema provides 100% coverage by definition. The description adds no parameter information, but none is needed. The baseline for zero-parameter tools is 4, and the description meets it.

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 the specific verb 'List' and clearly identifies the resource 'all enrolled courses for the current student', distinguishing it from blackboard_get_course which presumably targets a single course. The scope is explicit and 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 does not explicitly state when to use this tool versus alternatives like blackboard_get_course or blackboard_list_contents. The usage is implied by the name and description but not explicitly differentiated, so it falls into 'implied usage'.

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

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 signals a read operation, and the note that students only see posts from their groups in group discussions is a valuable behavioral quirk beyond the basic listing behavior. It does not mention output shape or ordering, but those are secondary for a read/list tool.

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 short, purposeful sentences. The core action is front-loaded, the group-discussion nuance is included because it changes results, and the sibling-tool routing is stated directly. There is no redundant or filler 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 an 8-parameter list tool with no annotations and no output schema, the description covers the most important context: what is read, the group visibility behavior, and how to handle replies. The schema already documents parameters like limit, offset, and filters. It is slightly incomplete in not describing return format or pagination behavior, but it is otherwise sufficient for an agent to select and invoke the tool correctly.

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 does not add parameter-specific semantics beyond the schema, but it does reinforce the groupId context by explaining group-based visibility. No additional explanation is necessary because every parameter already has a meaningful description in 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 reads top-level discussion messages/posts, identifies the specific resource (Ultra discussion), and distinguishes it from the sibling blackboard_list_discussion_replies by explicitly noting replies are not included. This gives an agent a precise, actionable understanding of the tool's purpose.

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 names the alternative tool, blackboard_list_discussion_replies, and states the condition for using it: reading replies with a messageId. This effectively communicates when to use this tool versus the sibling, leaving no ambiguity about the read-replies workflow.

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

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

No annotations are provided, so the description must carry the behavioral burden. The verb 'Read' implies a non-destructive operation, but no details about return format, pagination behavior, or any quirks (e.g., whether nested replies are included) are disclosed. The description adds little beyond the verb itself.

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 a single concise sentence with no fluff. It is front-loaded with the core action and resource, but given the tool's complexity (9 parameters), a slightly more informative description would be appropriate without becoming verbose.

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 9 parameters and no output schema, the description is too minimal. It does not explain the relationship to sibling tools, the expected return structure, or any usage caveats. An agent would need to infer a lot from the schema alone, which is insufficient for a list operation with pagination and filters.

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 all parameters already have descriptions in the schema. The tool description adds no extra meaning about parameters, but the baseline of 3 applies because the schema handles the parameter documentation adequately.

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 states a clear verb ('Read') and resource ('replies to a discussion message/post in an Ultra discussion'), making the purpose unambiguous. It does not explicitly differentiate from siblings like blackboard_list_discussion_messages or blackboard_get_discussion_thread, but the operation is specific enough to understand what it does.

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?

There is no guidance on when to use this tool versus the related siblings (e.g., blackboard_list_discussion_messages, blackboard_get_discussion_thread). The description only says what it does, not when to choose it. No alternatives, exclusions, or context are provided.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states the operation is read-only and that only discussions accessible to the current student are returned, which are important behavioral traits. It also acknowledges that topic bodies may not always be exposed by Blackboard. It does not mention pagination details or rate limits, but those are less critical for a read-only list operation.

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 with no filler. The main action is front-loaded, and each sentence adds distinct value: output content, access constraints, and read-only behavior. It is appropriately sized for the tool's complexity.

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 has five parameters and no output schema, but the parameters are fully described in the schema. The description gives the essential return information ('titles and topic bodies') and access scope. It does not describe the exact list item structure or sorting, but for a simple listing tool the current description is largely sufficient for selection and 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?

Schema description coverage is 100%, so the input schema fully documents all five parameters. The description does not add parameter-level details, but it is not required to because the schema already handles that responsibility. This aligns with the baseline of 3.

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 and resource: 'List Ultra discussions in a course'. It also clarifies the output content ('titles and topic bodies'). It does not explicitly differentiate from sibling tools like blackboard_get_discussion or blackboard_list_discussion_messages, though the listing-oriented wording makes the core purpose clear.

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 implies when to use the tool: when you need a list of course discussions. However, it provides no explicit guidance about when not to use it or when a sibling like blackboard_get_discussion or blackboard_list_discussion_messages would be more appropriate. The access caveat is useful context, but not a full usage guide.

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

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

With no annotations, the description carries the behavioral burden. 'Read' clearly signals a non-mutating operation, and 'complete conversation threads ... including all messages and embedded file attachments' discloses that the tool returns full thread content rather than summaries. It does not mention authentication or error behavior, but for a read-only listing tool the core transparency is present.

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 with no waste: the first front-loads the action, resource, scope, and depth of content, while the second states the optional filter. Every clause 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?

For a read-only tool with three optional parameters and no output schema, the description is largely sufficient: it states exactly what is returned and the available filter. It does not describe the response shape or pagination, but the schema already documents limit/offset defaults, making these minor gaps.

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% description coverage for all three parameters, so the baseline is 3. The description adds only a restatement of the optional courseId filter and does not enrich the meaning of limit or offset beyond what the schema already provides.

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 ('Read') and names a precise resource: complete conversation threads in the current student's Blackboard inbox. It also clarifies that embedded attachments are included and that results can be scoped by course, which separates it from discussion-board tools like blackboard_list_discussion_messages.

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 clear context for when this tool is relevant: reading inbox conversation threads, optionally for one course. However, it never explicitly states when not to use it or names alternatives such as discussion-message tools, so an agent must infer routing from the word 'inbox' rather than being directed.

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

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

Without annotations, the description carries the behavioral disclosure burden. It transparently reveals a key privacy behavior: 'Contact email is only included for instructors — classmates' emails are never returned, even with search.' This adds meaningful context beyond basic listing, though it does not describe all return fields or error handling.

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, front-loaded sentences. The first identifies the subject, the second gives the primary use case, and the third covers search and the important privacy 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 there is no output schema, the description partially explains return content (instructors and classmates, contact email for instructors only) but does not explicitly list all fields. The main functionality and notable edge case (email privacy) are covered, making it reasonably complete for a simple list tool.

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 both parameters described. The description adds minimal extra value: 'Pass search to look up one person by name' restates the schema's 'Name of one person in the course.' The description does not introduce syntax or format details 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 lists instructors and classmates of a course, with a specific use case: resolving an internal user id into a person's name. It distinguishes itself from sibling tools by focusing on course people, not courses, announcements, or assignments.

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 clear usage context: 'Use it to resolve an internal user id into a person's name' and 'Pass search to look up one person by name.' It gives practical guidance on when to use the tool, though it does not explicitly mention when not to use it or name alternatives.

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

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

The description adds a behavioral detail beyond the annotations by stating that modifying methods require direct user confirmation. This is valuable context for an agent, as it indicates an additional authorization step for non-read-only operations. The annotations already declare destructiveHint=true, so the description complements rather than contradicts them.

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 short sentences that convey the core function and a critical safety caveat. There is no fluff or redundant information; every word 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 raw nature, the schema covers parameter details and annotations cover safety, the description provides a sufficient warning about mutating methods. While it does not explain response formats or error handling, those are implicitly raw API responses, and the description is adequate for a pass-through tool. A slightly higher score would require explicit guidance on endpoint paths or response expectations.

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% parameter descriptions, so the description does not need to repeat parameter details. The baseline of 3 applies here since the description adds no additional parameter semantics beyond what the schema already provides.

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 'Call a public Blackboard REST API endpoint,' which specifies the action (call) and the resource (public Blackboard REST API endpoint). This distinguishes it from the sibling tools, which provide high-level operations like listing courses or retrieving user info. The name 'blackboard_raw_api' also reinforces this distinct purpose.

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 a clear usage caveat: 'Modifying methods require direct user confirmation through MCP elicitation.' This tells the agent when extra steps are needed for destructive operations. While it does not explicitly mention alternatives or say 'use this when no specific tool exists,' the 'public endpoint' qualifier and the existence of specialized siblings imply its role as a fallback or raw access tool.

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

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

Annotations already signal write behavior (readOnlyHint=false), but the description adds valuable context: the attempt remains open with status InProgress and no submission occurs. This clarifies the draft behavior beyond mere flags.

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 purpose and followed by clarifying exclusions. Every sentence adds value without 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 has no output schema, so return values are not needed. The description explains core behavior, state implications, and the exclusion of submission, which is sufficient for a draft-save tool. Slight gaps exist around failure conditions but are not critical for this operation.

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%, so parameters are well-documented. The description adds a high-level mapping ('text, attached files, or both') but does not go beyond the schema's existing parameter explanations, matching the baseline for full 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 saves progress on an assignment attempt without submitting it, specifying text, attached files, or both. It explicitly distinguishes from the sibling submit tool, making its 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 provides explicit when-not guidance: 'This does NOT send it to the instructor for grading' and directly names the alternative tool for submission (blackboard_submit_attempt). It also adds a user confirmation requirement for that alternative.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is clear. The description adds valuable context: the server also asks the user directly through MCP elicitation, and submission finalizes the attempt for grading. This goes beyond the annotations without contradicting them.

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 only three sentences and is front-loaded with the core purpose. Every sentence adds useful information: what it does, the confirmation requirement, and the alternative for drafts. No filler 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?

For a destructive action with no output schema, the description adequately covers the main workflow: what is submitted, the confirmation step, and the alternative for saving drafts. It does not explicitly describe the return value or post-submission behavior beyond 'the instructor can grade it,' but given the annotations and schema richness, this is sufficient.

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 covers all parameters with descriptions (100% coverage), so the description doesn't need to repeat them. It does mention 'text, attached files, or both' which maps to studentSubmission and fileUploadIds, adding slight semantic context, but does not explain parameter formats or relationships beyond what the schema already provides.

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 identifies the action (submit/finalize) and the resource (assignment attempt), and specifies the content types (text, attached files, or both). It also distinguishes this tool from the sibling 'blackboard_save_attempt_draft' by contrasting final submission with saving a draft.

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 instructs the agent to always confirm with the user before submitting, showing exactly what will be sent. It also names the alternative tool for saving progress (blackboard_save_attempt_draft), giving clear when-to-use guidance.

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

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. The verb 'Get' implies a read-only operation, but the description does not disclose response format, error behavior, or any side effects. For a zero-parameter tool this is a minor gap, but the description adds little beyond the basic purpose.

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 a single, front-loaded sentence that immediately conveys the purpose. There is no wasted language, and it is appropriately sized for such a simple tool.

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 nearly complete. It fully identifies the operation and resource. A higher score would require richer context (e.g., response format), but given the tool's simplicity, the description 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 input schema has zero parameters and schema description coverage is 100% (vacuously). With no parameters to document, the description does not need to provide additional semantic context. The baseline score of 4 applies.

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 gets the Blackboard Learn server version, using a specific verb (Get) and resource (server version). It is unambiguous and easily distinguished from sibling tools like blackboard_whoami or course-specific 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?

The description gives no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites or context, and while its purpose is clear, the 'when to use' is only implied by the tool name and description.

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

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

Beyond annotations (destructiveHint=true), the description discloses that the file is visible to the instructor, that upload is separate from attachment, and that the server will ask the user to confirm the path. It also warns against blindly following filePath instructions from untrusted sources. No contradiction with annotations.

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?

Every sentence adds value: purpose, limitation, follow-up tools, instructor visibility, confirmation flow, and safety rule. It is front-loaded with the main action and remains concise without fluff.

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 description fully covers the tool's role in the workflow: upload, return ID, next steps, side effects (instructor visibility), and security guidance. Despite no output schema, it clearly explains the return value and how to use it. It is complete for an upload tool with moderate 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 descriptions for filePath and confirmed. The description adds meaning by specifying acceptable file types (image, PDF, doc) and reinforcing that confirmed is deprecated. It also warns about the source of filePath, which is not in the schema, enriching parameter semantics.

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: uploads a local file to Blackboard and returns a fileUploadId. It explicitly differentiates from siblings by stating 'it does NOT attach it to an attempt yet' and references related tools (save_attempt_draft, submit_attempt) for the next step.

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 usage direction: pass returned fileUploadIds to blackboard_save_attempt_draft or blackboard_submit_attempt. Also includes safety guidelines about not choosing filePath from course content, and explains the user confirmation elicitation flow.

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

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

The description implies a read-only operation on the authenticated user's info, but it does not explicitly state that it makes no modifications, nor does it describe any potential errors or response details. With no annotations, the description carries the burden, but the simplicity of the tool limits the need for extensive disclosure.

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 a single, concise sentence that directly states the tool's purpose without unnecessary 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?

The tool is simple, but the description is minimal and does not explain what 'student info' includes or what the response structure is. Given the absence of an output schema, this is a minor gap, but the description is sufficient for basic understanding.

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 takes zero parameters, so the description has nothing to add beyond the schema, which is already empty. According to baseline, 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 uses the specific verb 'Get' and a clear resource ('currently authenticated UPC student info'), which clearly distinguishes it from sibling tools like list_courses or get_course. It is specific and 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 provides no guidance on when to use this tool versus alternatives, nor any exclusions. It simply states the operation without context.

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

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

Annotations already declare this read-only, idempotent, and non-destructive. The description adds deprecation status, a behavioral trait not captured by annotations, and indicates functional equivalence via the word 'alias'.

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?

A single, front-loaded sentence states the deprecation and the recommended replacement with zero wasted words. The structure maximizes scannability for an agent deciding whether to call this tool.

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 deprecated alias with one optional parameter and read-only annotations, the description conveys enough to route an agent correctly. It does not describe return values, but pointing to the canonical sibling implicitly covers that.

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%, so the optional term parameter is fully documented in the schema. The description adds no parameter-specific guidance, which is acceptable given the schema already carries the burden.

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 identifies the tool as a deprecated alias for banner_get_weekly_schedule and directs users to the canonical sibling. It does not restate the underlying operation, but the name plus the named target make 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 states that banner_get_weekly_schedule should be used for new integrations, providing clear routing away from this alias. It implies legacy use may still exist but does not spell out whether this tool is still operational.

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

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

Annotations declare readOnlyHint=true, and the description adds two useful behaviors: pagination via nextCursor and the security note that library content is untrusted data. It doesn't discuss rate limits or response shape, but with read-only annotations and low mutation risk, the added context is meaningful.

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 short sentences, each with a distinct purpose: scope, pagination, and data trust. No filler or redundant restatement of the tool name.

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 simple read-only list operation with two optional parameters and no output schema, the description covers target, pagination, and a key security caveat. It would be more complete if it explicitly tied nextCursor to the cursor input parameter and referenced alternative group-related tools, but these are relatively minor gaps.

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?

With 0% schema description coverage, the description partially compensates by introducing the nextCursor continuation mechanism, which is not in the schema. However, it never explicitly maps nextCursor to the actual `cursor` parameter, and it adds nothing beyond the schema for `limit`. This is adequate but has a clear mapping ambiguity.

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 states a specific action and resource: 'List references in the connected user Mendeley library.' This clearly identifies the root user library as the scope and is distinguishable from siblings like campus_mendeley_list_groups and campus_mendeley_list_group_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?

It gives clear context for use: list references in the connected user's Mendeley library and continue pagination via nextCursor. It does not explicitly name alternatives or say when not to use group-document tools, but the scope wording makes the intended context clear.

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

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

readOnlyHint already declares the operation safe and non-destructive, but the description adds value beyond the annotation by disclosing the return shape (folder endpoint supplies IDs only, not titles) and that pagination continues via nextCursor. It still omits whether a folder must exist or what happens with an invalid folderId.

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 tight sentences, front-loaded with purpose, then data-shape caveat, then pagination. Minor cost: the parameter-name mismatch introduces ambiguity rather than clarity.

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?

No output schema, so explaining that only IDs are returned is genuinely useful, and pagination is covered. But for a 3-param tool with 0% schema coverage, omission of limit semantics and folderId requirements leaves the definition short of 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 description coverage is 0%, so the description carries the full burden for three parameters, yet it only addresses pagination and does so with the wrong name: 'nextCursor' versus the schema's 'cursor'. Neither limit nor folderId (the required UUID) is explained.

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?

Clear verb+resource: list document IDs for a Mendeley folder. It implicitly distinguishes itself from nearby siblings like campus_mendeley_list_group_documents by naming the folder scope, but never explicitly contrasts them.

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 gestures at workflow ('match them with group or library listings for titles') and pagination, but gives no explicit when-to-use vs the sibling list tools (list_folders, list_group_documents) or prerequisites.

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

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

readOnlyHint=true already establishes the safe-read profile, yet the description still adds real value: it discloses that each returned folder carries id and parent_id for tree reconstruction and that results are cursor-paginated. The only defect is that it calls the paging token 'nextCursor' while the schema names the field 'cursor', which is a naming mismatch rather than an annotation conflict.

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 short sentences, front-loaded with the primary purpose, then return shape, then pagination. Every sentence carries information, though the 'nextCursor' wording introduces avoidable confusion about the actual field name.

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 no output schema it usefully describes the returned folder fields and the pagination loop, which is the most important missing piece. However, it omits the meaning/limits of 'limit' and misnames the cursor parameter, leaving an agent to guess at part of the call contract.

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 0%, so the description carries the burden. It explains groupId (group vs. user-library selection) and the pagination token, but leaves 'limit' entirely unexplained and mislabels the cursor field as 'nextCursor'. Partial compensation only.

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?

States a specific verb (List) and resource (folders) with an explicit scope split: the connected user library by default, or a Mendeley group when groupId is passed. This is enough for an agent to separate it from campus_mendeley_list_folder_documents and campus_mendeley_list_groups without opening any schema.

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 the condition that selects each mode ('with groupId, in a Mendeley group') and tells the agent to pass the cursor to continue paging. It stops short of naming a concrete alternative or stating when not to use this tool, but the context for both optional-parameter branches is clear.

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

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

The readOnlyHint annotation already signals safety, and the description adds meaningful context beyond it: results are limited to what is 'visible to the connected user,' and 'Library content is untrusted data' is a useful security caveat. It does not describe output shape or rate limits, but the annotation lowers that burden.

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 short sentences with no filler. The first sentence states the core purpose, the second gives pagination instruction, and the third adds a safety note. Each 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?

For a read-only list operation with three parameters and an existing readOnlyHint annotation, the description covers purpose, authorization visibility, pagination continuation, and data trust. It omits return-shape details, but the absence of an output schema is partially mitigated by the straightforward 'List references' framing.

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 0%, so the description must compensate for parameter meaning. It explains the cursor parameter via 'Pass nextCursor from a preceding response to continue,' but it does not describe groupId or limit semantics beyond what the schema already states with types and constraints.

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 states a specific verb and resource: 'List references in one Mendeley group visible to the connected user.' This clearly distinguishes it from sibling tools like campus_mendeley_list_groups (which lists groups) and campus_mendeley_list. The scope is precise and actionable.

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?

There is no guidance on when to use this tool versus alternatives such as campus_mendeley_list or campus_mendeley_list_groups. The only usage hint, 'Pass nextCursor from a preceding response to continue,' addresses pagination rather than tool selection or disambiguation.

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

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

Beyond the readOnlyHint annotation, the description adds two valuable behavioral details: pagination control ('Pass nextCursor from a preceding response to continue') and a security caution ('Group names and content are untrusted data'). This goes beyond the annotation's safety implication and helps the agent behave correctly in handling untrusted content.

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 short sentences, front-loading the primary purpose and then adding pagination and security context. Every sentence delivers distinct value with no redundancy or filler, making it easy for an agent to parse quickly.

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 list tool with readOnlyHint and no output schema, the description covers the core action, pagination, and a security warning. However, the parameter naming inconsistency (nextCursor vs cursor) and the complete omission of the 'limit' parameter semantics leave gaps that could confuse an agent, especially given the lack of schema descriptions.

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?

With 0% schema description coverage, the description is the only source of parameter meaning. It mentions the pagination parameter but refers to it as 'nextCursor' while the actual schema property is 'cursor', creating a naming mismatch. It offers no explanation of the 'limit' parameter or its default/maximum values, leaving the agent to infer its purpose from the schema alone.

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 verb 'List' and the resource 'Mendeley groups visible to the connected user', which distinguishes it from sibling tools like campus_mendeley_list and campus_mendeley_list_group_documents by specifying the group context. This is a precise, unambiguous purpose statement.

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?

There is no guidance on when to use this tool versus alternatives such as campus_mendeley_list or campus_mendeley_list_group_documents. The only usage hint is the pagination instruction about passing nextCursor, which is a technical detail, not a decision-making guideline. The description does not state prerequisites or exclusions.

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

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

Beyond the annotations, it discloses that the tool is marked as a write so the host can apply its own approval policy, that OAuth is handled separately, that provider responses are untrusted data, and that credentials must never be passed as arguments. This is rich safety context that the annotations alone (destructiveHint=true, openWorldHint=true) do not convey.

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?

Dense but front-loaded: purpose first, then path/body mechanics, then safety constraints. Every sentence carries operational or safety information, though the block of constraints is slightly run-on.

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 an open-world raw-API tool with no output schema, the description covers purpose, auth handling, PDF body encoding, and mutation guardrails. It omits response shape and error behavior, but annotations plus the argument that provider responses are untrusted partially compensate.

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 0% across 9 parameters, so the description must carry the load. It documents path format (relative under api.mendeley.com) and the PDF body convention (bodyBase64 vs sourceUrl with contentType application/pdf), but method, query, accept, headers, and body are left to the schema's bare types. Partial compensation only.

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?

States a specific verb and resource – 'Call an authenticated Mendeley Core API path' – and scopes it explicitly to 'operations not exposed by a dedicated tool,' which cleanly distinguishes it from campus_mendeley_list_folders, campus_mendeley_save_doi, and the other Mendeley siblings. An agent can tell immediately that this is the escape hatch, not a routine operation.

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 names the selection rule (only for operations with no dedicated tool), the precondition for mutation ('only modify the library when the student explicitly requests the exact action'), review steps for uploads, and clear handling for deletions. Alternatives and when-not-to-use are both covered.

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

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

The description adds behavioral context beyond annotations by disclosing that it verifies exact Crossref metadata, scans for duplicates, and explicitly states what it does not do. This complements the annotations (readOnlyHint false, destructiveHint false, etc.) without contradiction, giving the agent a fuller picture of side effects 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 three sentences with no filler. It front-loads the primary purpose, adds a usage directive, and then provides behavioral limitations. Each sentence serves a distinct purpose, making it efficient and well-structured, though it could be slightly more compact by merging the last two sentences.

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 two-parameter tool with no output schema, the description covers the essential information: what it does, when to use it, what it verifies, and what it avoids. It omits details like return format or error handling, but given the simplicity and existing annotations, it is sufficient for an agent to call it correctly.

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?

With 0% schema description coverage, the description needed to explain the parameters but only mentions groupId in passing ('when groupId is provided') and does not elaborate on doi format or constraints. The schema provides basic type/length info, but the description adds minimal semantic value beyond that, failing to compensate for the missing schema descriptions.

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 action (save), the object (DOI reference), and the target (user library or writable group). It distinguishes the tool from siblings like campus_mendeley_list by focusing on the save operation and explicitly lists what it does not do (certify peer review, upload PDFs, share content), leaving no ambiguity about its purpose.

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 instructs to use it only when the user asks to save a DOI, providing a direct condition for invocation. It does not name alternatives, but the 'only when' phrasing clearly differentiates it from sibling tools that handle listing or searching. The guidance is unambiguous and sufficient.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false. The description adds real behavioral context beyond that: it checks all target pages for the same URL before writing (a dedup guard) and can target a writable group. Auth requirements and return behavior remain unstated.

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?

Front-loaded with the core action and constraint, and every sentence maps to a real concern (routing, required metadata, dedup, integrity rules). The 'Do not invent...' and 'Use only when...' rules add length but earn their place as guardrails.

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 7-parameter mutation tool with no output schema, the description covers purpose, routing, dedup behavior and the group target. It omits return value and permission prerequisites, but the annotations already carry the safety profile, so the gaps are minor.

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 0%, so the description must carry the parameter burden. It clarifies url (HTTPS), title (exact) and groupId (optional writable group), but leaves type, year, source and authors completely unexplained, so roughly half the parameters are undocumented in both places.

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?

States a specific verb (Save) and resource (reference) and immediately scopes it with 'without a confirmed DOI', which distinguishes it from the sibling campus_mendeley_save_doi. An agent can route correctly without opening either schema.

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 condition 'without a confirmed DOI' implicitly routes to save_doi for DOI-confirmed cases, and 'Use only when the user asks to save it' sets a clear trigger. It stops short of explicitly naming the alternative tool, so it's strong but not fully explicit about when-not.

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

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

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing semantic caveats: no_extractable_text is not proof of a blank page or OCR failure, and visualReviewRecommended is a lead rather than visual inspection. It also scopes what the tool cannot certify, which is exactly the kind of behavioral context annotations don't carry.

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?

Front-loads the purpose, then layers caveats that each carry real decision value. It is somewhat dense but no sentence is filler given the interpretability warnings.

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 no output schema, the description does a good job explaining how to interpret the manifest's signals and what the tool cannot prove, which is critical for an audit tool. The gap is parameter explanation and any indication of the manifest's structure, but for interpretation guidance it is largely 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 description coverage is 0% across three parameters (analysisId, documentId, includePages). The description only hints that the PDF must be 'prepared' but never explains what analysisId, documentId, or includePages mean or their defaults, so it fails to compensate for the missing schema documentation.

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?

States a specific verb and resource ('Create a page-by-page audit manifest for a prepared PDF') and enumerates what it classifies (extracted text, truncation, figure/table/box signals), making it distinguishable from read/index siblings. It does not name an alternative explicitly, but the scope is 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?

Provides workflow guidance ('Use the original PDF resource link to inspect flagged pages, then state exactly which pages were inspected') and states limits ('cannot certify whole-document critical reading'), but never says when to prefer this over campus_research_index_pdf, index_status, or read_indexed_pdf. Usage is implied rather than routed.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds substantial behavior beyond those: dependency on SERPAPI_API_KEY, unverified output, fallback to a labeled manual search link, and non-official Google status. There is no contradiction with the annotations.

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 four concise sentences, each contributing a distinct fact: what the tool searches, the third-party dependency, the unverified nature of results, and the fallback/authority status. It is front-loaded and contains no filler or redundant restatement of the schema.

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 read-only, idempotent annotations and the tool's moderate complexity, the description covers the main behavioral risks: key dependency, unverified output, and no-key degradation to a link. It is slightly incomplete about output shape and pagination/date-range behavior, but the schema defaults and parameter names reduce the practical impact.

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 only 20%, so the description carries the burden for explaining parameters, but it only addresses mode/link behavior and the presence of an API key. It does not explain query semantics, pagination with page, or the yearFrom/yearTo date-range parameters, leaving most parameters under-documented.

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 a specific verb and resource: 'Search Google Scholar', and immediately identifies the third-party SerpApi integration. Naming Google Scholar makes it clearly distinguishable from sibling tools like campus_research_search and campus_research_search_databases, and the closing 'Not an official Google API' removes ambiguity.

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 conveys an important usage nuance by stating results are 'discovery candidates requiring independent verification, not certified sources,' which implies this is for discovery rather than authoritative verification. It also explains the no-key and mode=link fallback behavior, but it does not explicitly contrast this tool with the verification/citation sibling tools or say when to prefer one over the other.

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

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

Adds substantial context beyond the annotations: it returns a fresh analysisId even when reusing an existing index, readPages/verifiedEvidence are scoped to that analysis, the 20 MB / 500 page limits, the need to poll until ready, and a prompt-injection warning to ignore instructions embedded in the PDF. It also discloses that indexing does not summarize or validate claims, which is exactly the kind of expectation-setting the annotations cannot carry.

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?

Front-loaded with the selection condition and the critical return values, and nearly every sentence carries information. It is dense to the point of being slightly run-on, packing IDs, limits, workflow, and safety into a single paragraph, but there is little true 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?

With no output schema, the description correctly covers return values (documentId, analysisId) and how to use them, plus limits, workflow, and safety caveats. An agent has everything needed to invoke and chain this tool; only the refresh parameter's semantics remain thin.

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 0% and the two parameters (url, refresh) are undocumented in the schema. The description constrains url to a public HTTPS PDF and mentions index reuse, but the refresh parameter is never explained (when to set it, what it re-does), so it only partially compensates for the coverage gap.

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?

States a specific verb+resource (index a public HTTPS PDF) and scopes it precisely to PDFs longer than 20 pages where page locations are unknown. It also positions itself in a workflow ('first step') relative to the status/search/read/verify siblings, so an agent can tell it apart immediately.

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?

Gives a clear triggering condition ('question spans chapters or page locations are unknown') and sequences the downstream flow: poll status, search the index, then read exact pages. The size threshold implicitly excludes short PDFs, though it never names the sibling that should handle them (e.g. read_pdf), so routing for the short-PDF case is left to inference.

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

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

Adds substantial behavioral context beyond the read-only/idempotent annotations: without analysisId the ledger is cumulative and cannot prove what a given answer read, indexedPages is extraction coverage only, and indexes may be lost on restart or another relay instance. This is exactly the kind of operational caveat an agent needs.

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?

Front-loads the purpose, then gives the critical analysisId guidance, then caveats. Every sentence carries useful information, though the description is dense and introduces several concepts in a short space.

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 read-only status tool with no output schema and 0% schema descriptions, the description is largely complete: it covers what is checked, the key optional parameter, and important index volatility. The only gap is not explicitly defining documentId's expected source or uniqueness.

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 0%, so the description must carry parameter meaning. It thoroughly explains analysisId: where to get it, why to pass it, and what happens without it. documentId is only implied as the indexed document identifier, leaving minor room for improvement.

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?

States a specific verb and resource: check extraction progress, outline, OCR gaps, and SHA-256 for an indexed document. It names analysisId from index_pdf and distinguishes this status/ledger tool from the index creation sibling.

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?

Gives clear contextual guidance: pass analysisId from index_pdf to get readPages and verifiedEvidence, and explains the consequence of omitting it. It does not explicitly compare against audit_indexed_pdf or search_index, but the intended usage context is clear.

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

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

Annotations already cover readOnly/idempotent/destructive, so the bar is lower, yet the description adds real operational context: the 20 MB ceiling, that it does not bypass paywalls, logins or DRM, that formulas are not recalculated, and that CSV/XLSX coordinates are preserved. These are exactly the behavioral traits an agent needs and cannot infer from annotations.

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?

Front-loaded with the core action and format list, then layered with constraints (ZIP, size, legal limits). Dense but every sentence carries distinct information; slight overrun in enumerating formats twice (once in the opening list, once for routing rules).

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 no output schema and a complex multi-format tool, the description covers formats, routing, bounds and legal constraints well, but the section-based chunking parameters (sectionCount/startSection) are only obliquely referenced, so an agent lacks full guidance on how to page through a large document.

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 only 25%, so the description must compensate, and it does for format: it explains that auto covers HTML/text/XML/CSV/PDF and that ZIP requires an explicit docx/epub/xlsx. It implies sectionCount/startSection through 'bounded section-based evidence' but never explains pagination or the sectionCount/startSection relationship, leaving a partial gap.

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?

Names a specific verb (Read) and resource (a public HTTPS academic document) plus the format set, and explicitly distinguishes itself from the sibling campus_research_read_pdf by stating 'PDF is routed to the specialised page reader.' An agent can route between read_document, read_pdf and read_indexed_pdf without opening a schema.

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?

Gives concrete conditions: ZIP files require format=docx/epub/xlsx, and PDF goes to the specialised reader. It does not explicitly name when NOT to use this tool (e.g. vs read_source_file) or state prerequisites beyond the paywall/login exclusion, so it falls short of full when/when-not guidance.

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

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

Adds substantive behavior beyond the annotations: it operates on an already-completed index (implying index_pdf/index_status prerequisites), the page cap, persistent OCR/layout caveats, and a prompt-injection warning to ignore instructions embedded in the PDF. The annotations already cover safety/idempotence, but the limitation and injection notes are genuine added value.

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?

Four front-loaded sentences with no filler, leading with the core action and limit. It is dense but each clause carries information; minor density in the analysisId scoping clause keeps it from a 5.

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 read-only tool with no output schema, the definition covers prerequisites, page limits, limitations, injection safety, and the follow-up verification path. It stops short of describing returned content shape or failure behavior when the index is not yet 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 0% with 4 params, so the description must compensate. It meaningfully explains analysisId (where it comes from and why scoping matters) and contextually places documentId in the verification flow, while 'up to 5 exact pages' corroborates startPage/pageCount; however startPage/pageCount semantics are only indirectly addressed.

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?

States a specific verb (read), resource (pages from a completed, cached PDF index), and scope limit (up to 5 exact pages, no re-download/parse). The caching framing distinguishes it from the sibling campus_research_read_pdf that presumably fetches and parses fresh.

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?

Gives a clear prerequisite and routing: pass analysisId from index_pdf so pages belong to this answer, and for quotations call campus_research_verify_evidence. It does not explicitly state when to prefer this over read_pdf/read_document, so the alternative-selection guidance is implicit rather than spelled out.

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

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

Annotations already cover readOnly/idempotent/openWorld, but the description adds substantial context: each call re-downloads and re-parses, no OCR, no paywall bypass, no peer-review verification, no layout preservation, and the resource link persists even on processing failure. It also warns to ignore embedded instructions in the PDF, a meaningful safety disclosure.

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?

Dense and front-loaded: core action and limits come first, then routing guidance, then exclusions. Long but nearly every clause adds operational value; the exclusions are borderline verbose but defensible for a safety-sensitive fetch tool.

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 no-output-schema fetch tool, the description covers the return shape (page-numbered evidence + resource_link), the failure mode (link remains available), and the input limits. An agent has what it needs to call it correctly and to decide against it when indexing is better.

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 0%, so the description must carry parameter meaning. It conveys the 20-page-per-call limit (mapping to pageCount's maximum) and 'specific pages' (implying startPage), but never explains the startPage semantics, the default of 5 for pageCount, or the 1-based indexing. Partial compensation only.

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?

States a specific verb+resource ('Read specific pages of a public HTTPS PDF') with scope limits (20 MB, 20 pages/call) and return content ('page-numbered evidence plus a resource_link'). It clearly distinguishes itself from the indexed-PDF siblings by naming the exact alternative pipeline.

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?

Explicitly instructs when to use this tool versus the alternative: for PDFs longer than 20 pages with unknown/spread pages, use index_pdf then index_status/search_index/read_indexed_pdf instead of repeatedly paginating. This is a concrete when/when-not routing rule naming the alternatives.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavior beyond them: 20 MB file cap, 20-page-per-call cap, re-fetch/re-parse on every call, temporary file URL not returned, no OCR, and no automatic scientific validation. These are exactly the operational constraints an agent cannot infer from the annotations.

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?

Front-loaded with the core purpose and conditions, then constraints, then the alternative-tool routing. Dense and information-rich, though the anti-overclaiming instruction ('do not claim a complete review') and the citation-caveat sentence make it longer than strictly necessary.

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 read-only, no-output-schema tool, the description supplies the missing return-relevant context (temp URL not returned, sourceUrl is unverified) plus limits, re-fetch behavior, and the alternative-tool path. An agent has everything needed to invoke it correctly and interpret its limitations.

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 0%, so the description must carry the load, and it does for the important ones: pageCount ('up to 20 pages per call'), page ranges (startPage intent), and sourceUrl ('an unverified bibliographic claim until title, authors and publication are compared with the PDF'). It is weaker on the nested source_file fields (file_id, download_url, file_name, mime_type), which are never explained, leaving a small gap.

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?

States a precise verb+resource (read specific pages of a student-attached PDF), plus the triggering condition (publisher URL cannot be fetched by Campus). It explicitly names the sibling it is not (campus_research_index_pdf), so an agent can distinguish it from the other campus_research_* readers without opening any schema.

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?

Gives an explicit when-to-use ('PDF explicitly attached by the student... when its publisher URL cannot be fetched') and a when-to-prefer-something-else ('If a public PDF URL is available and relevant pages are unknown or spread across chapters, prefer campus_research_index_pdf'). It also instructs how to behave on long PDFs (select page ranges, report pages read, don't claim full review).

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description still adds real behavioral value: candidate URLs are unverified until read and checked for title, DOI, hash and passage, and source coverage is conditional on an exact DOI match.

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 dense but well-formed sentences; the resolution outcome is front-loaded and the caveat about unverified candidates follows. It is on the verbose side, but no sentence is redundant.

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 no output schema, the description usefully enumerates the return surface (source-specific candidates and matching landing-page/file candidates) and states the verification caveat. The main remaining gap is that it never explains the verification workflow a caller should follow next.

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?

Only one parameter (doi) and the schema carries a 0% description coverage, so the description must compensate. It says 'exact DOI', implying exact-match input rather than fuzzy lookup, but adds nothing about format, prefix handling, or the 6-350 length bounds.

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 a concrete verb+resource ('Resolve an exact DOI ... into public Crossref/DataCite, OpenAlex, OpenAIRE, Europe PMC ... and Zenodo candidates'), which is far more specific than the sibling verify_doi or read_document tools. It does not name a sibling to route against, but the scope is 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?

There is no statement of when to choose this tool over campus_research_verify_doi, read_document or search. The conditional clause about OpenAIRE/Europe PMC/Zenodo only matching on an exact DOI is a resolution rule, not usage guidance, so the agent must infer the selection context.

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

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

Annotations already establish readOnly/idempotent/non-destructive and openWorld, so the bar is lower, yet the description still adds real context: it discloses the return shape (metadata, DOI, provenance, pagination), the auth prerequisite, and an epistemic caveat that indexing does not prove peer review. That is meaningful behavior beyond the structured fields.

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 tight sentences with the core action front-loaded and no filler. The caveat sentence earns its place by preventing misuse, though it could be trimmed slightly.

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 7-parameter, low-coverage, no-output-schema tool, the description covers the return payload and a key caveat but leaves several parameters (yearFrom/yearTo, limit caps, page) unexplained and does not clarify provider-specific behavior. Adequate but with clear gaps.

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 only 14%, so the description should compensate more than it does. It conveys that pagination and provider selection exist, and it implies year/provider-related usage, but it never explains page/limit bounds, yearFrom/yearTo semantics, or how provider choice changes results.

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?

States a specific verb (Search) and resource (academic publications) and names concrete providers, which separates it from generic sibling tools like campus_research_search_databases or campus_research_google_scholar. However, the named providers (Crossref, OpenAlex, ACM, Scopus, Web of Science) are only a subset of the enum's 10 values, and no sibling is explicitly contrasted.

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 line about provider API keys is a useful prerequisite, and 'verify candidates before citing' implicitly routes to the verify_* siblings. But there is no explicit when-to-use vs alternatives (e.g., versus campus_research_google_scholar or campus_research_search_databases), leaving selection to inference.

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

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

Annotations already establish readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely non-redundant behavior: it returns per-database results or explicit access errors rather than failing wholesale, and it preserves provenance, which tells the agent to expect partial failures and per-source attribution.

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 tight sentences with the operation stated first and the parameter rules next; every line carries information. Only the closing Crossref-prefix fact feels mildly tangential for an agent that will not control the prefix.

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 no output schema and six parameters, the description covers the highest-risk ambiguity (date range semantics) and the failure mode, but omits provider selection behavior and limitPerProvider meaning. It is adequate but leaves gaps an agent would have to guess at.

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 only 17%, so the description must compensate, and it does explain the semantics and mutual exclusivity of the year parameters ('inclusive', 'calendar years ending now', do not combine). It says nothing about query constraints, providers selection, or limitPerProvider, leaving half the parameters undocumented in both places.

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?

It names a specific verb (Search) and names the exact resources (ACM publications, Scopus, Web of Science), which differentiates it from the generic campus_research_search and campus_research_google_scholar siblings. The trailing sentence about Crossref prefix 10.1145 muddies rather than sharpens the scope, since the tool claims to search ACM directly while also routing through Crossref.

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 gives real selection guidance between two mutually exclusive date parameterizations (yearFrom/yearTo vs recentYears) and warns against the 'assume three years' default. However it never says when to pick this tool over campus_research_search, campus_research_google_scholar, or campus_research_search_index, so sibling routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: results are 'ranked page snippets as discovery leads, not scientific conclusions' and it instructs the agent to verify excerpts before citing. It could still say more about pagination or empty-result 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?

Three dense sentences, front-loaded with the core action, then the dependency, then the caveat. Nothing is wasted, though the sentences are packed and could be split for scannability.

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 and no annotations gap on safety, the description supplies the critical missing knowledge: the upstream dependency, the ledger/analysisId linkage, and the required verification mindset. It stops short of documenting the other three parameters or return shape.

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 0%, so the description must compensate. It covers analysisId semantics well (passed from index_pdf to keep the ledger separate), but says nothing about documentId, query, or limit. Partial compensation earns a mid score.

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?

Clear verb+resource: 'Search a completed PDF index by meaningful words.' It implies a prior indexing step and names a dependency (index_pdf via analysisId). It doesn't explicitly differentiate itself from the many sibling search/read tools (campus_research_search, campus_research_read_indexed_pdf), so it lands at 4 rather than 5.

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 implies usage ('Search a completed PDF index', 'Pass analysisId from index_pdf') but never states when to choose this over siblings like campus_research_read_indexed_pdf or campus_research_search. Prerequisites are hinted, not specified as exclusions or alternatives.

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

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds real behavioral content beyond them: the exact failure conditions that produce citeAllowed=false (mismatch, absent record, incomplete metadata, retraction, exact editorial update), pointers to retractionNotices/editorialNotices, and the constraint that citationRecord is registry-only and must never be completed by inference. That is unusually rich disclosure for a read-only check.

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?

Dense but front-loaded: the purpose and the precondition come first, then failure modes, then the evidence caveat. Every sentence carries information, though the middle clause packing five failure conditions into one sentence is slightly compressed.

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?

There is no output schema, so the description must carry return semantics — and it does, naming citeAllowed, retractionNotices/editorialNotices, and citationRecord's registry-only nature, plus the downstream evidence requirement. An agent has enough to call this correctly and interpret the result.

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 75%, with the schema itself documenting expectedYear, expectedTitle, and expectedAuthors match semantics. The description only implicitly covers doi/expectedTitle ('a discovered title', 'DOI record') and says nothing material about expectedYear or expectedAuthors beyond what the schema already states, so it adds little over the structured fields.

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?

States a specific verb ('strictly verify') and resource ('a discovered title ... against an exact Crossref or DataCite DOI record') and frames the precondition ('before citing it'). This distinguishes it from sibling verifiers like campus_research_verify_doi and campus_research_verify_document_identity, which target DOI validity and document identity rather than title-to-registry match.

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?

Clear context is given: run this before citing a discovered title, and the earlier claim still requires document identity and page/section evidence. However, it never names the sibling alternatives (verify_doi, verify_document_identity, verify_evidence) or states when those would be preferred over this tool, so routing is only partly guided.

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

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is set. The description adds genuinely useful traits beyond that: 'Fails closed on a mismatch' and the scope limit 'Does not judge scientific claims'. It still doesn't describe the shape of a mismatch/failure result, which keeps it from 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core check, then the conditional PDF case, then the behavioral boundary. Dense but every sentence carries information; the middle sentence is slightly overloaded but not wasteful.

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 7-parameter, no-output-schema verification tool, the description covers the identity-matching rule, the fallback author/year path, failure behavior, and the scope boundary. Gaps remain around the url/format parameters and the concrete form of a success or failure response, but the core decision-relevant context is present.

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 0%, so the description carries the full burden. It explains the semantics of five of seven parameters (expectedSha256 as the file identity, expectedTitle, expectedDoi 'when provided', expectedAuthors as a canonical short author list, expectedYear in the matching rule) and the matching logic that ties them together. It leaves url and format unexplained, so not a 5.

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 states a specific verb and resource: checking that an already-read file (identified by required SHA-256) contains an expected bibliographic title and DOI. This implicitly distinguishes it from the read_* tools that produce the file and from verify_doi/verify_citation, which operate on identifiers rather than a local artifact. It stops short of explicitly naming which sibling it replaces, so a 4 rather than 5.

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 makes the precondition explicit ('the already-read file', required SHA-256) and gives a concrete conditional usage path: when the DOI appears only in a self-citation after the abstract, pass canonical expectedAuthors and expectedYear. It does not state when NOT to use it versus verify_doi or verify_citation, so it falls short of full routing guidance.

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

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

Beyond the provided annotations, the description discloses the fallback sequence, error interpretation rules, inclusion of correction/retraction notices, and scope limits such as not certifying peer review or scientific validity. This adds substantial behavioral context for an agent.

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 front-loaded with the core lookup behavior, then efficiently covers edge cases and scope limits. Every sentence earns its place, and there is no redundant or filler text.

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 single-parameter lookup tool with no output schema, the description covers fallback behavior, error semantics, retraction notices, and scope boundaries. It could say more about the returned record, but the critical invocation and interpretation guidance is present.

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 0%, so the description must compensate. It adds the key semantic that the DOI must be exact, but it does not specify format, normalization, or examples beyond what is implied by the standard DOI format.

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 states a specific verb and resource: look up an exact DOI in Crossref, with DataCite as fallback. It clearly distinguishes the operation from broader research tools by specifying exact-DOI verification and describing retraction/correction checking.

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 gives clear conditions for when the DataCite fallback applies (Crossref 404 or 429/503) and warns that temporary Crossref failure plus DataCite 404 is still an upstream error, not absence. It does not explicitly name sibling alternatives, but the usage context is well defined.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavior: evidence is rejected if expectedSha256 no longer matches, a stable evidenceId is returned, and integrity checking is textual only (semantic judgment left to the caller). That exceeds the annotation payload meaningfully.

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 sentences, front-loaded with the core action, then reuse mechanics, then the returned artifact and the caller's residual responsibility. Dense but every clause carries information; the metadata-heavy schema itself is what makes it feel long.

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 10-parameter, no-output-schema tool, the description covers the primary workflow, the reuse path, the failure mode (hash mismatch), and the return handle (evidenceId). Optional params like inspectPreviousPage and expectedSha256 are handled adequately by schema text.

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 80%, so baseline is 3, but the description adds cross-parameter semantics the schema cannot express: documentId/analysisId/URL must be passed together to reuse a prepared index instead of re-downloading. Page/section/format details remain in 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?

States a precise verb and resource: 'Verify a client-selected excerpt at its exact PDF page or document section.' An agent can tell this apart from verify_quote/verify_citation at a high level, though it never explicitly contrasts itself with those close siblings.

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?

Gives actionable context: pass documentId+analysisId+original URL to reuse a prepared page and SHA-256, and points to campus_research_index_status for reporting. It also sets the boundary of responsibility ('the client AI must still judge whether the excerpt supports its claim'). Missing an explicit 'use verify_quote instead when...' routing against siblings.

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

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

The description adds rich context beyond annotations: it specifies fail-closed logic, exact DOI registry metadata checks, retraction and editorial update checks, SHA-256 and title/DOI presence in the file, and page/section sentence verification. It also lists supported formats and clarifies that fragments remain partial and wider context needs review. Annotations only cover read-only, idempotent, and open-world, so this adds substantial value.

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 dense but front-loaded with the core purpose and every sentence earns its place: it covers checks, formats, alternatives, and limitations without any filler. It is a single paragraph but logically ordered and appropriately sized.

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 a complex tool with 10 parameters, no output schema, and annotations that only cover safety, the description is largely complete: it explains the verification logic, supported formats, and key limitations. It could be more complete by detailing the roles of url, expectedYear, and expectedAuthors, but it provides enough for an agent to understand the tool's purpose and behavior.

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?

With only 30% schema description coverage, the description must compensate but only partially does. It implies doi, expectedSha256, expectedTitle, quote, page, and section through phrases like 'same file SHA-256', 'title and DOI in the file', and 'complete quoted sentence on the stated PDF page or document section', and lists format values. However, it does not explain url, expectedYear, or expectedAuthors, leaving significant gaps.

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 states a specific verb (check) and resource (full-sentence quotation) with multiple fail-closed conditions, clearly distinguishing it from verify_evidence for CSV/XLSX data. However, it does not differentiate itself from the sibling tool verify_quotes (plural), leaving a potential routing ambiguity.

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 explicitly names the alternative verify_evidence for CSV/XLSX rows or cells and notes that data locators are not complete sentences. It also implies usage for full-sentence quotations, but does not cover when to choose it over verify_quotes or other sibling verification tools.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds real behavioral context beyond them: the return payload ('per-quote status and allExcerptsLocated') and a precise semantic boundary (location only, not claim support), plus the index_pdf dependency for documentId/analysisId.

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 action is front-loaded in the first sentence, and every following sentence carries distinct information (inputs, returns, usage constraint, scope limit). Dense but not padded; only the stacked clauses make it slightly heavy going.

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 5-required-param tool with 0% schema description coverage and no output schema, the definition covers inputs, provenance, return fields, and the key semantic limitation. The main residual gap is the absent contrast with the singular verify_quote sibling, which an agent selecting between them would need.

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 0%, so the description must carry the load and largely does: it maps documentId/analysisId to their origin in index_pdf, identifies url and expectedSha256 as the original URL and hash, and clarifies that citations are page/excerpt pairs. It omits the excerpt length bounds and per-field format expectations, so it is not fully compensating.

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?

States a specific verb (check/verify) and resource (every literal quotation planned for one answer), with batch scope made explicit via 'one cached-PDF call (up to 8)'. The singularity sibling campus_research_verify_quote is never named or contrasted, so the agent must infer the batch-vs-single distinction from the 'up to 8' phrasing alone.

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