Axis LMS MCP by usefulapi

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the 'WRITE:' prefix adds little. What does add value is the membership precondition and the note that groups drive course/path assignments, hinting at downstream effects. It still omits what happens on failure (e.g., error when already a member) and whether assignment propagates immediately.

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 compact clauses, front-loaded with the write nature and the precondition, with no filler. The trailing raw endpoint is slightly redundant with the name but does document the resource shape.

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-required-parameter mutation with no output schema and adequate annotations, the essentials are covered: operation, precondition, and endpoint. It is silent on return value or failure behavior, which leaves a modest gap for an agent chaining calls.

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% for both parameters, so the schema supplies only types. The description partially compensates by naming both parameters in the endpoint template (POST /usergroups/members/{usergroup_id}/{user_id}/), clarifying the path ordering, but gives no ID format or source guidance.

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 ('add a user to a usergroup') and the parenthetical precondition clarifies the exact operation. It is trivially distinguishable from axislms_remove_usergroup_member and axislms_list_usergroup_members 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 precondition 'they must not already be a member' gives a real when-to-use constraint, and 'Groups can drive course or path assignments' hints at why one would do this. However, there is no routing to alternatives such as axislms_enroll_user_in_course or axislms_list_usergroup_members (to verify membership first), so usage is only implied.

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=true and destructiveHint=false, so safety is covered. The description adds pagination behavior (100 per page) and clarifies that returned dates are YYYYMMDD while the filter params use yyyy-mm-dd — useful, but it says nothing about the count_only mode, ordering of results, or permissions scope.

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: what is returned, how to filter, and pagination mechanics — front-loaded with the resource and field list, with no filler. Slightly dense but every clause carries 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?

With 12 parameters, no output schema, and read-only annotations, the description does the important work of enumerating the returned fields and the page size, compensating for the missing output schema. The undocumented count_only shortcut and result ordering are the remaining 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 92%, so the schema already documents the filter grammar, operators, and date patterns in detail. The description only groups the filters into users/number/method/dates, adding little beyond that baseline; the output-vs-filter date format hint is the one real contribution.

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 resource and scope: certifications issued within one certification program, with the returned fields enumerated. It does not name or differentiate itself from plausible siblings such as axislms_list_user_certificates, axislms_list_certification_users, or axislms_get_certification, so an agent must infer the distinction.

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?

"Filter by users, number, method and dates. Paged (100 per page)" implies how to narrow results, but there is no explicit when-to-use guidance, no exclusions, and no pointer to the sibling that returns a single certificate or a per-user certificate list.

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 annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful qualifier that only active online courses are counted, but does not mention return type, authentication, or scoping behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two short fragments with no wasted language. The purpose is front-loaded, followed by the relevant endpoint path.

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 count tool with annotations covering safety, the description is nearly sufficient. A minor gap is that it does not state the return type, such as an integer count, but the operation is simple enough that this is not a major omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The tool has zero parameters, so there is no parameter semantics burden on the description. The empty schema makes the no-argument invocation clear, and the baseline for zero parameters is a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource and scope: a count of active online courses. It distinguishes the count operation from sibling listing tools like axislms_list_courses, though it does not explicitly name the alternative.

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

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

Usage is implied by the count-focused wording: use this when only a number is needed rather than a course list. However, the description gives no explicit when-to-use or when-not-to-use guidance versus axislms_list_courses.

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=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds the underlying REST endpoints, which clarifies what the call actually hits, but says nothing about the response shape, whether the count is exact, or rate/permission constraints.

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 short sentences with the purpose front-loaded and zero padding. The raw endpoint strings are slightly cluttered but do carry information about the two modes (all vs filtered).

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 a single optional, fully documented parameter and complete read-only annotations, the description covers what an agent needs. The only mild gap is not stating outright that a single numeric count is returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100% and the user_filter parameter is documented in exhaustive detail (operators, fields, examples). The description only glosses the parameter as 'a search phrase', adding no syntax or behavior beyond the schema, so the 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?

States a specific verb+resource with scope: a count of users, either all or matching a search phrase. An agent can tell this is the counting counterpart to list_users/search_users, though no sibling is named explicitly.

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 it (when a number is wanted rather than a list) but never says so directly and names no alternatives such as search_users or list_users. An agent must infer the choice from the word 'Number'.

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?

Read-only, non-destructive annotations cover the safety profile, and the description adds genuine context beyond them: the inclusion criteria, pagination at 100 per page, and the output date encoding (YYYYMMDD). With no output schema, it does the work of describing the return shape reasonably well, though it omits sort order and 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?

Four dense sentences, front-loaded with the payload contents before the filtering and constraints. The trailing 'GET /reports/courses/{course_id}/' is marginally useful for API mapping; the '100 per page' detail duplicates the page parameter description but is cheap.

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 13-parameter, no-output-schema report, the description covers what is returned, the inclusion rule, and pagination – enough for correct invocation. Remaining gaps (range-pair semantics, count_only interplay, sort order) are minor and partly covered by the schema.

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?

Coverage is 54%; the description lumps status, progress, score and date filters together without explaining that score/progress/date are min/max range pairs or giving the status enum semantics. The heavy lifting (user_filter grammar, page, count_only) is already in the schema, so a 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?

States clearly that this is a per-user report for a single course, enumerating the returned fields (user, status, progress %, score, start/completion date) and the endpoint. That distinguishes it in substance from list_course_users (roster) and user_report (cross-course), though no sibling is named explicitly.

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 inclusion rule ('limited to users currently enrolled who accessed the course or have score data') hints at when this report is appropriate, but there is no explicit when-to-use / when-not / alternative routing against user_report or certification_report. Usage is implied rather than stated.

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 non-read-only, non-idempotent, open-world behavior, and the description still adds real value: the temporary password is never returned, access must be granted through the LMS itself, and the user may be notified depending on settings. Those side-effect disclosures go beyond the annotations, though reversibility/cleanup on a bad create is not addressed.

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?

Five tight sentences, front-loaded with the WRITE marker and the resource, then constraints, then return value, then the password caveat. No filler, though the password sentence is slightly long-winded.

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?

It covers the return value (new user id) compensating for the missing output schema, and handles the most dangerous ambiguity (password). However, for a 31-field create tool it says nothing about which fields are meaningful, how role/manager_id affect the account, or what permissions are required.

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 31 parameters and only 13% schema description coverage, the description documents just one field (username format and uniqueness). Role enum, manager_id, dates, localization and the fifteen custom fields are left entirely to bare names, which is a large gap for a create call.

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?

Opens with a specific verb and resource ("WRITE: create a new LMS user") plus the endpoint, which cleanly separates it from get_user, update_user and the search/list siblings. An agent knows exactly what this does without opening 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?

It gives useful preconditions (username format and uniqueness) and explains where the password comes from, which implicitly tells the agent not to attempt password delivery here. But it never names alternatives such as update_user for existing accounts or search_users to verify availability, so routing guidance is implied rather than stated.

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 useful context beyond that: the name validation rules, that it returns the new id, and the underlying POST route, which helps the agent understand what to expect back.

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, front-loaded fragments with no filler; the operation type, constraint, and return value all appear immediately.

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 create tool with rich annotations and no output schema, the description covers the name constraint and the returned id, which is enough to call it correctly. Only the duplicate-name/uniqueness behavior is missing.

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 parameter burden, and it does: it restates the 4-99 character limit and the allowed character set (letters, numbers, spaces, @ . _ -) in readable prose, matching the schema pattern. It does not explain whether names must be unique.

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 usergroup") and even names the endpoint. It is clearly distinguishable from siblings like get_usergroup or add_usergroup_member by the name itself, though it doesn't explicitly contrast with axislms_create_user.

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 "WRITE:" prefix signals it is a mutating operation, but there is no guidance on when to use this vs alternatives (e.g., to fetch an existing group use get_usergroup, to list use list_usergroups) and no prerequisites or duplicate-name behavior is mentioned.

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 flag write/destructive/idempotent/open-world, and the description adds genuine value beyond them: the active-entity prerequisite, the upsert-like date-change path, and the possible notification side effect. That is exactly the contextual disclosure 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-loads a 'WRITE:' marker, then packs preconditions, update behavior, and side effects into three tight sentences. Zero 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?

For a destructive mutation with no output schema, the description covers prerequisites, the idempotent re-enroll case, and notifications. The only shortfall is not mentioning unenroll_user_from_course as the reversal path or what a successful response looks like.

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 start and end are described in the schema (50% coverage); user_id and course_id have no descriptions at all. The description clarifies the dates' role as access/enrollment dates but does nothing to disambiguate the two undocumented IDs, so it adds marginal value over 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 concrete verb and resource ('enroll a user in an online course') and even names the endpoint, so the action is unmistakable. The word 'course' separates it from the enroll_user_in_ilt_session and enroll_user_in_learningpath siblings, though it never explicitly contrasts with 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?

Gives real preconditions ('user and course must be active') and a distinct secondary mode ('if the user is already enrolled, send start or end to change the enrollment dates'). It does not point at an alternative tool, but the conditions for correct use are 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?

The annotations already disclose readOnly=false, idempotent=false, and destructive=false, so safety is covered; the description earns credit for adding that the call "takes a seat" and for naming the capacity check. It remains silent about failure modes, such as behavior when the session is full or the user is already enrolled.

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 compact sentence front-loads the write classification, then the action, then the prerequisite, then the endpoint, so the important detail appears first. Every clause contributes, though the endpoint string is partly 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?

For a three-parameter mutation with annotations covering the safety profile and no output schema, the description covers the core action and a practical precondition. Missing details about the return value and conflict handling are minor but not negligible.

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 names program_id, session_id, and user_id only through the endpoint path, without stating what each identifier refers to. Because the names are largely self-explanatory, this baseline-level coverage is just adequate.

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 definition opens with a specific verb ("enroll") and resource ("a user in a session of an ILT program"), and the "ILT" qualifier separates it from sibling enroll tools for courses and learning paths. It also shows the endpoint shape, which reinforces the operation's exact direction.

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 supplies a concrete prerequisite, telling the caller to "check seats_remaining with axislms_list_ilt_sessions first", and names that sibling tool directly. However, it never states when not to use this tool, such as using the unenroll sibling to reverse an enrollment.

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=false, idempotent=false, destructive=false, and openWorld=true, so the safety profile is covered. The description adds real value beyond that: the explicit 'WRITE' marker, the 'must not already be enrolled' precondition (which explains why the call fails on repeat), and the requirement that the user be active. It does not describe the response or error behavior, keeping 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 short, information-dense sentences with the operation type and action front-loaded and zero filler. Every sentence adds a distinct fact (write type, precondition, endpoint).

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 write tool with no output schema, the description covers operation type, preconditions, and endpoint. It lacks any statement about failure behavior (e.g., what error occurs if already enrolled) or confirmation response, which would fully close the loop, but nothing essential for correct invocation is missing.

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 of explaining the two parameters. It partially compensates by embedding the endpoint template POST /learningpaths/enrollments/{learningpath_id}/users/{user_id}/, which implies the role of each path parameter, and the names are self-explanatory. However, no format or constraint detail is added beyond the template.

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 (enroll a user in a learning path) with the 'WRITE:' tag making the operation type immediately clear. The resource name distinguishes it from the sibling enroll_user_in_course and enroll_user_in_ilt_session tools without further explanation.

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 preconditions: the user must be active and must not already be enrolled, which tells the agent when the call is valid. It does not explicitly route to alternatives (e.g., unenroll_user_from_learningpath or the course/session enrollment siblings), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set and the underlying endpoint, but says nothing about error behavior for a nonexistent id, auth requirements, or any rate limits.

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?

One compact sentence, front-loaded with the resource and its fields. The telegraphic style (no verb) costs it a little, but nothing is wasted.

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 single parameter, the description carries most of the burden and does list the return fields, which is the main gap it needed to fill. It stops short of describing not-found behavior or how it relates to the list and report siblings.

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 single program_id parameter is undocumented in the schema. The description only surfaces it indirectly through 'GET /certifications/{program_id}/', which conveys it is a path identifier but not its type or constraints (positive integer).

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 the resource ('One certification program') and enumerates the fields returned (name, prefix, description, tags, webhook, status), so the agent knows this is a single-object read. Sibling differentiation is only implicit via 'One' vs. list_certifications – it never names the 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?

Usage is implied: fetch one program by id, as opposed to list_certifications for a collection. There is no explicit when-to-use, no prerequisite, and no mention of the closely related axislms_certification_report or axislms_list_certification_users, which an agent might reasonably confuse it with.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the HTTP endpoint and the full field inventory of the response, but says nothing about errors, 404 behavior, permissions, or rate limits.

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 resource and its attributes, ending with the endpoint for orientation. The attribute list is long but each item is a concrete field name, so nothing is padding.

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

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

With no output schema, the field enumeration in the description effectively documents the return payload, which is the key missing piece an agent would need. The only real gap is that it doesn't say how to recover from an invalid id or what an empty/missing course looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

There is exactly one parameter and schema description coverage is 100% ('Axis course id (from axislms_list_courses)'), so the schema fully documents it. The description adds nothing about course_id, which is acceptable given full schema coverage — baseline 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?

States the resource precisely (one online course) and enumerates the returned attributes plus the underlying endpoint GET /courses/{id}/, so the retrieval purpose is unambiguous. It doesn't explicitly contrast itself with axislms_list_courses or axislms_course_report, so sibling differentiation is only implied by 'One'.

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?

'One online course' implies a single-record fetch as opposed to the list variant, which is weak but present guidance. There is no explicit when-to-use/when-not or named alternative among the many course-related siblings (list_courses, count_courses, course_report).

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the field set and the REST path, but says nothing about error behavior for unknown ids or rate limits.

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 compact fragments, front-loaded with what the tool returns. Slightly telegraphic but no wasted 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 single-parameter read tool with safety annotations and a listed return field set, this is nearly sufficient; an output schema is absent but the description names the fields, so an agent can 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?

Schema description coverage is 0% and the description does not clarify program_id beyond its self-evident name; the integer/positive constraint exists only in the schema. With a single unambiguous parameter this is a minor gap rather than a blocking one.

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 concrete verb+resource ('One ILT program') and enumerates the returned fields (name, catalog id, description, keyword tags), which distinguishes it from list_ilt_programs. It stops short of explicitly naming the list sibling as the alternative.

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

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

Usage is only implied: the singular framing suggests fetching one known program versus listing many, but there is no explicit 'use this when you have a program_id' guidance or named 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 readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral note, 'Contains personal data', which flags privacy handling concerns, plus the underlying GET endpoint. It does not cover permissions/scope requirements or filtering behavior 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?

A single dense sentence that is front-loaded with the core purpose before the field enumeration; nothing is wasted. The long parenthetical field list is slightly heavy but it carries real information about returnable data.

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 takes on the burden of describing what comes back, and it does so by enumerating the retrievable data domains. Safety and scope are covered by annotations plus the personal-data warning; only access requirements are unaddressed, which is minor for a read-only lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100% and both parameters are well documented, so the baseline is 3. The description nevertheless groups the fields enum into semantic clusters (profile sub-fields, usergroups, courses, ILT classes, certifications, learning paths, badges, organizations, sysvars), which helps an agent reason about what to request rather than just reading a flat 40-value enum.

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 with an explicit scope qualifier: 'One user by id with the fields you ask for'. The 'by id' framing distinguishes it from the sibling list/search user tools without ambiguity, and it enumerates the data domains (profile, usergroups, courses, ILT, certifications, etc.) that can be retrieved.

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 when-to-use or when-not-to-use guidance and never names an alternative such as axislms_search_users, axislms_list_users, or axislms_user_report. The only routing hint ('from axislms_list_users or axislms_search_users') lives in the schema's user_id description, not in the tool description itself, so usage 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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value by enumerating the returned fields (name, active/inactive/total counts, owner), which matters because there is no output schema. It omits failure behavior for a nonexistent id, keeping 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?

Two compact fragments with the return payload front-loaded, which is exactly what an agent scanning for output shape needs. Slightly telegraphic phrasing ("One usergroup:") costs a little polish but no waste.

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 field enumeration is the key piece of information and it is present; annotations handle the safety profile. Missing only error/not-found semantics and permission requirements for a tool of this complexity, which is a minor gap.

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 single parameter usergroup_id is undocumented in the schema. The endpoint template GET /usergroups/{id}/ implies the parameter is a usergroup identifier, but the description never states the id type, valid range, or what happens on a bad id.

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?

"One usergroup" plus the GET /usergroups/{id}/ endpoint states a specific resource and singular scope, which distinguishes it from the sibling list_usergroups. It stops short of an explicit verb like "fetch/retrieve", leaving the agent to infer the operation from the endpoint string.

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 never says when to use this tool rather than list_usergroups or list_usergroup_members, nor that it is the only way to get counts without page-walking users. Usage is implied by the singular resource wording but no alternative is named.

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=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds meaningful context beyond that: the fixed page size of 100 and the underlying endpoint GET /reports/ilt/{program_id}/, which signals the report scope is a single program. It stops short of describing pagination termination behavior or rate limits.

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 that front-load the return payload, then filtering, then paging and endpoint. No filler, and the most decision-relevant information (what columns you get) comes first.

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

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

For a 15-parameter, output-schema-less report tool, enumerating the returned fields is exactly the right compensating move. The description is nearly complete; the only real gap is routing guidance versus the other ILT listing tools, which matters given how many siblings exist.

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 67% schema description coverage, the schema already documents page, status, user_filter, session_name and the date bounds thoroughly. The description's mention of users/status/session/dates aligns with those parameters but adds no syntax or semantics beyond them, and it says nothing about method_earned, count_only, or the meeting-count range filters.

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 resource (attendance and results of one ILT program) and enumerates the returned columns, so an agent knows exactly what data comes back. It implicitly distinguishes itself from siblings like axislms_list_ilt_sessions or axislms_list_user_ilt_sessions by being a program-scoped report, but it never names those alternatives explicitly.

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?

'Filter by users, status, session and dates' gives implied usage context for narrowing results, but there is no explicit guidance on when to choose this over axislms_list_ilt_completions, axislms_list_user_ilt_sessions, or axislms_get_ilt_program. The agent must infer the selection criteria from the tool name alone.

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=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds that results are paged at 100 per page and names the underlying endpoint, but says nothing about permissions, sorting, or pagination termination. It also gives output dates as 'YYYYMMDD' while the schema filters use yyyy-mm-dd, which risks confusion rather than clarifying 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?

Two compact sentences with the resource and returned fields front-loaded, then pagination and endpoint. No filler, though the endpoint string earns little for an agent.

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 10 parameters, no output schema, and a read-only report role, the description covers the returned columns and page size, which is the essential part. It omits how count_only changes the reply shape and how the date-range filters interact with the reported dates, leaving gaps for an agent planning a filtered query.

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 70%, so the schema already documents most parameters, including the user_filter syntax and count_only. The description merely restates the status and active/archived enum values and repeats the 100-per-page fact already in the page parameter, adding no new parameter meaning.

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: enrollments and results for one learning path, plus the fields returned (user, status, active/archived, start/completion date). It does not distinguish itself from the closely related sibling axislms_list_learningpath_users, so an agent must infer the difference.

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

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

Usage is only implied by 'for one path' and the required learningpath_id. There is no explicit statement of when to prefer this over axislms_list_learningpath_users or axislms_list_user_ceus, and no prerequisites are mentioned.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful value by disclosing the thin projection (id and name) and the underlying endpoint, but says nothing about pagination, result caps, or ordering.

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 short clauses plus the endpoint path, with the purpose and the filter front-loaded and no filler. The enum restatement is slightly redundant against the schema but costs only a few 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?

For a one-optional-parameter read-only list with no output schema, the description covers the resource, the filter, and the shape of the returned objects, which is enough to invoke it correctly. Only pagination and result-size expectations are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100% and the single enum parameter is fully documented with its default, so the schema already carries the semantics. The description repeats the enum values and the endpoint template but adds no format or behavioral detail beyond them, making the baseline 3 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 gives a specific verb and resource ('List certification programs') and adds the returned projection ('id and name'), so the agent knows this is a lightweight listing rather than a detail fetch. It does not explicitly contrast with axislms_get_certification or axislms_list_certification_users, which keeps it from a 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?

Usage is only implied by the status filter ('active, inactive or all'), which hints at scope but not at when to choose this over a sibling. Nothing states when to use get_certification for full records or list_certification_users for enrollment data.

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=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds value by naming the returned fields (id and username), but says nothing about pagination, result size limits, or what happens for an empty/unknown program.

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 compact clauses, front-loaded with the resource and return fields, followed by the endpoint. No filler, though the terseness leaves gaps that could have been filled with one more sentence.

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 read tool with no output schema, the description usefully discloses return fields, but omits pagination behavior, ordering, and whether the caller needs certification-admin permissions. Adequate minimum, not 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% and the only hint that program_id is a certification program id comes indirectly from the GET path /certifications/{program_id}/users/. The description never states the parameter's meaning, valid source, or failure mode for a nonexistent id, so compensation is partial at best.

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: users certified in a certification program, with the endpoint path confirming the resource hierarchy. It clearly implies program-scoped listing rather than per-user certificates, but doesn't explicitly name the distinction from siblings like axislms_list_user_certificates or axislms_certification_report.

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 when-to-use or when-not-to-use guidance. With close siblings (axislms_certification_report, axislms_list_user_certificates, axislms_list_users) available, an agent gets no routing hint about which to pick for which question.

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 readOnlyHint, destructiveHint and openWorldHint, so the description's burden is lighter. It still contributes real behavioral information beyond them: the result set is silently filtered to 'active online' courses (not all courses), and the response contains only id, name and a count rather than full course objects. It says nothing about pagination or result limits for a parameterless list call.

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?

One front-loaded sentence that states scope, return fields and count with no filler. The trailing raw endpoint 'GET /courses/list/' adds little for an agent but is minor.

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, non-mutating list tool with no output schema, the description supplies the two things an agent needs: what subset of courses is returned and what fields come back. The only real gap is pagination/size behavior, which matters if the course catalog is large.

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 baseline is 4. The description correctly introduces no parameter concepts and instead describes the fixed output fields, leaving nothing ambiguous about inputs.

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 (list courses) and adds the scope and payload ('active online courses (id and name), plus the count'), which an agent could not infer from the name alone. It does not explicitly differentiate itself from close siblings like axislms_count_courses or axislms_get_course, so it falls short of a 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?

There is no statement of when to use this versus axislms_count_courses (which also returns a count) or axislms_get_course for a single course. Usage is only implied by the word 'List'; no prerequisites or exclusions are given.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that results include enrollment access start/end dates in YYYYMMDD format and exposes the REST path, but says nothing about pagination, result caps, or ordering for potentially large course rosters.

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 compact sentence that front-loads the resource and the returned fields, plus the endpoint path. No filler, though the endpoint string and the status enumeration duplicate information already available elsewhere.

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 carries the burden of describing returns and does partially do so (users plus access start/end dates). However, it omits pagination/volume behavior and the relationship between status filtering and the date fields, which matters for a list endpoint on a course roster.

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 50%: status has an enum plus a default note, while course_id is undocumented in the schema. The description restates the status options (redundant with the enum) and adds the YYYYMMDD date format context, but does not clarify course_id semantics or what 'active' vs 'expired' means relative to the returned dates.

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 the specific resource (users enrolled in a course) and the returned fields (access start/end dates), which distinguishes it from siblings like axislms_list_users or axislms_list_usergroup_members. The phrasing is a noun fragment rather than a verb+resource sentence, and it never explicitly names the siblings it is not, so it stops short of a 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?

The description lists the status values (active, expired, all) but never says when to choose this tool over axislms_list_users, axislms_search_users, or axislms_course_report. No when-to-use or when-not guidance is present; usage must be inferred from the title.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a useful return-shape hint (id and username), but says nothing about pagination, ordering, or volume, which matter for an open-world list endpoint with no output schema.

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 short, front-loaded sentences with no filler; the endpoint reference is compact. The telegraphic phrasing is slightly terse but efficient.

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 two-parameter read tool with annotations covering safety, the definition is nearly sufficient, and the stated return fields help compensate for the absent output schema. Missing pagination/ordering behavior and the undocumented required program_id leave 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 coverage is only 50%, with program_id entirely undocumented in the schema. The description partially compensates by framing program_id as the program scope and session_id as an optional narrowing, but it gives no format, validation, or interaction details beyond that.

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 the resource ('Users who completed an ILT program, or one session of it') and makes the program-vs-session scope explicit, plus the HTTP endpoint. It is clear what is returned (id and username). It stops short of differentiating from the closest sibling, list_user_ilt_sessions, which queries the same data from the user side.

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

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

Usage is implied by the scope statement: use it to get completions for a whole program or a single session. There is no explicit when-to-use/when-not guidance and no mention of the sibling that answers the inverse question (which sessions a user attended).

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the REST endpoint template, which hints at the resource hierarchy, but says nothing about pagination, result size, or required permissions for a tool flagged openWorld.

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 listing the returned fields plus the endpoint is efficient and wastes nothing. It is perhaps too terse given the parameter ambiguity, but not padded.

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 lists the returned meeting attributes (date, time, timezone, duration, GMT start/end, facility), which is the right compensation. It still leaves out pagination, empty-result behavior, and error conditions for a two-required-parameter lookup.

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; the endpoint template GET /ilt/{program_id}/meetings/{session_id}/ does clarify that program_id identifies the ILT program and session_id the session. It does not state types, whether the session must belong to the program, or what happens on a mismatched pair.

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 concrete resource (meetings of one ILT session) and enumerates the returned fields, so the agent knows exactly what is fetched. It implicitly distinguishes itself from axislms_list_ilt_sessions by scoping to a single session, but never states that contrast explicitly.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as axislms_list_ilt_sessions or axislms_get_ilt_program. The only usage signal is the implicit scoping to one session.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the endpoint and the exact fields returned, but says nothing about pagination, result limits, or ordering — a real gap for an openWorld list call.

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 plus endpoint reference, with no filler. The parenthetical efficiently conveys the returned fields at minimal cost.

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 read tool with annotations covering safety, the definition is nearly complete, and it compensates for the absent output schema by naming the returned fields. The only missing element an agent might want is whether results are paginated or capped.

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 baseline is 4; the schema is trivially complete. The description's only parameter-adjacent content is the return-field note, which is accurate and adds value without any risk of misdescribing inputs.

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 ('List instructor-led training (ILT) programs') and even discloses the returned fields (id and name) plus the underlying endpoint. It clearly separates from axislms_get_ilt_program (single program) and axislms_list_ilt_sessions, though it does not name those siblings explicitly.

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 explicit 'use when' statement or exclusions, but usage is strongly implied: the parenthetical '(id and name)' signals this is a lightweight lookup for discovering program IDs before calling axislms_get_ilt_program or enrollment tools. An agent can infer the role, but the routing is not 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 declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the endpoint path and the shape of the payload (dates plus total/reserved/remaining seats), but says nothing about pagination, ordering, or behavior when a program has no sessions.

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 telegraphic sentence that front-loads the resource and packs return fields plus scope into one line. Dense but no wasted tokens; the fragment style costs a little readability.

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 carries the burden of describing returns and does partially (dates and seat breakdown). It omits program_id semantics, pagination/volume expectations, and any note on empty results, leaving gaps for a list endpoint that may return many records.

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 50%: 'scope' is documented in the schema ('Default current.') and program_id has no description at all. The description restates the current/all distinction but adds no default behavior or constraint detail 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 names the resource precisely (sessions of an ILT program) and the fields returned (start/end dates, seat counts), which is materially more specific than the bare title. It stops short of explicitly differentiating from close siblings such as axislms_list_user_ilt_sessions or axislms_list_ilt_meetings.

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 'current ones or all' phrasing implies the filtering choice but never states when to pick each or when to prefer another sibling (e.g., per-user sessions vs program sessions). Usage is inferable rather than 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 establish readOnly, openWorld, and non-destructive behavior. The description adds useful context beyond them: the result contains only active learning paths and returns id and name fields. It does not disclose pagination or result limits, but the core behavioral shape is clear.

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 short sentences with the key scope ('active') and return fields front-loaded. The endpoint path is technical but does not obscure the primary description.

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 list tool with annotations and no output schema, the description covers the essential scope and return fields. It could mention pagination or whether all active paths are always returned, but nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The tool takes no parameters, so the schema cannot provide parameter semantics and the baseline is 4. The description correctly implies an unfiltered list of active learning paths, with no parameter details to compensate for.

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 gives a specific verb (List), resource (active learning paths), and return fields (id and name), plus the endpoint path. It is clearly distinct from sibling tools like learningpath_report and list_learningpath_users, but it does not explicitly name those alternatives.

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 when-to-use guidance, no exclusions, and no explicit comparison to alternatives such as learningpath_report or list_learningpath_users. The 'active' qualifier is the only usage constraint, and the agent must infer everything else.

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=true and destructiveHint=false, so safety is covered. The description adds a genuine behavioral trait beyond them — only *active* enrollments are returned — and enumerates the returned fields, but says nothing about pagination, result size, or error behavior for an invalid path id. Comparable to the HIGH calibration's 3 for an annotated read tool that adds a scoping constraint.

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 sentences, front-loaded with the resource and scope; nothing is wasted. The field enumeration is long but earns its place because there is no output schema, though the bracketed endpoint notation is slightly cryptic.

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 2-parameter read tool with no output schema, the description supplies the essential missing piece — what comes back (status, start/completion time, completion method, path version, current branch/step, progress). Only the absence of any pagination or volume expectation keeps it from being 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?

Schema coverage is only 50% (learningpath_id has no schema description), but the description compensates: 'of a learning path (or one user)' plus the 'GET /learningpaths/{id}/users/[{user_id}/]' template clarify that learningpath_id selects the path and user_id is an optional narrowing filter to a single enrolled user. That is meaningful added semantics over the raw integer types.

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 with scope: 'Active enrolled users of a learning path (or one user)'. The 'active enrolled' qualifier and the parenthetical single-user mode make the resource precisely identifiable against siblings like axislms_list_course_users or axislms_list_certification_users, though no sibling is named explicitly.

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

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

Usage is only implied by the resource: an agent can infer it lists learning-path enrollments. There is no explicit when-to-use vs. axislms_learningpath_report / axislms_list_course_users, no statement about prerequisites (e.g. needing an existing learning path id), and no note on when to pass user_id versus omitting 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 declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the genuinely useful fact that nested branches are returned and discloses the endpoint, but says nothing about pagination, result volume, or error behavior for an invalid organization_id.

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 compact fragments with no wasted words, and the key scope qualifier (nested branches included) is placed early. The trailing HTTP endpoint is mildly redundant but serves as a locator.

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 read-only list operation with no output schema and annotations carrying the safety profile, the description covers the essentials: what is fetched, for which organization, and that nesting is included. Return shape and pagination are the only notable omissions.

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 and schema description coverage is 0%, so the schema does not explain organization_id. The path template in the description implies it identifies the parent organization whose branches are listed, which adds meaning beyond the bare integer type, but no format or valid-value guidance is given.

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 the resource (an organization's branches) and adds scope detail (nested branches included), and the HTTP path pins it to a single organization. But it is a noun fragment with the verb supplied only by the title, and it never distinguishes itself from siblings like axislms_list_organizations or axislms_list_organization_users.

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 use this tool versus axislms_list_organizations or axislms_list_organization_users, and no prerequisites or conditions given. The only implicit guide is the required organization_id.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context (the returned fields and the owner_id=0 meaning) but says nothing about result size, ordering, or pagination behavior for a list endpoint over an open world.

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 covering scope, return fields, and the special-case id; nothing is redundant. The trailing URL template is marginally useful and slightly dense 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 one-optional-parameter read tool with no output schema, the description compensates by naming the returned fields (owner id, user count) and the two filter modes. Remaining gaps — ordering and pagination — are minor for this shape of 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% and the schema already explains the omit-for-all behavior, yet the description contributes the non-obvious semantic that owner id 0 means the partition admin — a value not inferable 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?

States a specific verb+resource ("List organizations") and adds what the response contains (owner id and user count), plus the two scoping modes. It is distinguishable from siblings like list_organization_branches or list_organization_users by resource, though it never names an alternative explicitly.

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?

"all or those owned by one manager" plus the owner-id-0 special case implies which mode to pick, but there is no explicit when-to-use/when-not guidance and no routing to related sibling tools such as list_organization_users.

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 read-only, open-world, non-destructive behavior. The description adds the endpoint path and lists returned fields (id, username, branch id), but it omits pagination, auth requirements, or other operational 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?

Very compact and front-loaded, with no filler. The parenthetical field list is slightly ambiguous about whether those are returned fields or parameters, which 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 simple two-parameter read tool with annotations and no output schema, it covers scope, status options, and returned fields. It still lacks sibling differentiation and pagination details, so it is adequate but incomplete.

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 50%: status is documented by the schema and the description reinforces its active/inactive/all options. organization_id is only indirectly explained by 'in an organization' and the path template, without format or requiredness clarification 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?

States the resource and scope clearly: users within a specific organization, with status filter options. It does not explicitly contrast itself with sibling tools like list_users or search_users, so it falls short of a 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?

No explicit guidance on when to use this tool versus the many sibling list/search tools. The organization-scoped usage is implied by the resource name and path, but alternatives and exclusions are not mentioned.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful beyond-annotation context — the date format (YYYYMMDD) and the underlying endpoint template — but says nothing about result size, ordering, or behavior for a user with no certifications.

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 naming the resource and its fields, with the date format attached where it matters. The trailing raw endpoint path is mildly redundant padding but earns some value as origin documentation.

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 the field enumeration and date format carry the return-value burden and do so adequately. Safety is covered by annotations; the only real gap is the undocumented meaning of user_id and any note on empty results.

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, user_id, and it has no description in the schema (0% coverage). The description merely embeds {user_id} in the endpoint template, which restates the parameter name without clarifying whether it is an internal ID vs external identifier or how to obtain 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?

States a specific verb+resource: the certifications held by a given user, and enumerates the returned fields (program, certification number, issue/renew/expire dates). It is distinguishable from axislms_list_certifications (all certifications) and axislms_list_certification_users (the inverse direction), though it never names those siblings explicitly.

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

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

Usage is implied by 'a user holds' — call it when you need one user's certifications. There is no explicit when-to-use framing, no exclusions, and no pointer to axislms_list_certification_users or axislms_get_certification as 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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful output context by naming the CEU fields returned and the REST endpoint, but it does not mention pagination, authorization requirements, or return structure beyond the field list.

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 compact sentences with no waste, front-loading the CEU fields and then the endpoint. The description is appropriately sized for a simple read-only list 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 simple one-parameter read-only list tool with no output schema, the description covers purpose and returned fields adequately. However, it omits pagination behavior, parameter details, and any usage guidance that would help an agent complete the call confidently.

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 the single user_id parameter. It mentions 'a user' and the endpoint path containing {user_id}, but it does not explain the parameter's type, format, or where to obtain the ID, leaving the only parameter largely undocumented.

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 resource (continuing-education credits/CEUs a user earned) and lists the returned fields, which clearly distinguishes it from certificate-oriented siblings. The description implies listing rather than saying so directly, but the name and title supply the verb.

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 no explicit guidance on when to use this tool versus alternatives such as axislms_list_user_certificates or axislms_certification_report. The implied usage is clear from the resource, but no context or exclusions are given.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that membership can be filtered by active/inactive/all and that only id and username are returned, but says nothing about pagination, result caps, or behavior when the usergroup does not exist — significant for a list endpoint.

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?

Very short, front-loaded, and every element (member fields, status options, endpoint) carries information. It borders on under-specification rather than verbosity, and the endpoint template is placed last where it helps least.

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 at least state the returned fields, and annotations cover the safety profile. However, for a paginated-style list tool with an undocumented required parameter, it leaves the agent without enough context on result volume or error conditions.

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 50%: `status` is documented in the schema (including its 'Default active.' note) and the description merely repeats the enum values. `usergroup_id` has no description in either place, and the description does not clarify that it is the group identifier path parameter, so the coverage gap is not compensated.

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 phrase 'Members of a usergroup (id and username)' names the resource and even the returned fields, and the endpoint path confirms it is a read/list operation. It is distinguishable from siblings like axislms_list_usergroups (groups, not members) and axislms_add_usergroup_member (mutation). It is a fragment rather than a full sentence, but the intent 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 guidance on when to call this versus axislms_get_usergroup, axislms_list_users, or the add/remove member tools. The status option implies a filtering choice, but no conditions or prerequisites (e.g. the group must exist) are stated.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that only id and name are returned, but does not mention pagination, result size, or other behavioral details.

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 very short and front-loaded with the core purpose and return fields. The included endpoint is useful but somewhat redundant for an agent invoking the 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, read-only list tool with annotations covering safety and no output schema, the description is largely complete. It identifies the returned fields, though it could clarify pagination or whether all groups are returned.

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 parameter semantics are inherently simple and the baseline is 4. There is no parameter documentation needed.

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 usergroups') and specifies the fields returned ('id and name'). It does not explicitly distinguish itself from sibling tools such as axislms_get_usergroup or axislms_list_usergroup_members, so it falls short of a 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?

Usage is implied: use this tool to list usergroups. There is no explicit guidance about when to use it instead of axislms_get_usergroup for a single group or axislms_list_usergroup_members for members.

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 annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful return-field context (program, session dates, percent attended) and the endpoint, but it does not disclose pagination, ordering, attendance semantics, or authentication 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?

The description is two compact clauses with no filler: return fields are listed first and the endpoint is provided last. It is appropriately sized for a simple one-parameter read-only listing 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 simple read-only tool with one required parameter and no output schema, the description is nearly complete: it states the resource, scope, endpoint, and key returned fields. It could be fuller by mentioning pagination or whether all session statuses are included, but the core calling information 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%, but there is only one parameter and the description shows it in the endpoint as {user_id} while referring to 'a user'. That clarifies the parameter’s role, though it does not explain the accepted user ID source or format beyond the schema’s integer constraint.

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 identifies a specific resource and scope: ILT sessions belonging to one user, and it previews the returned fields. It implicitly distinguishes itself from the sibling list_ilt_sessions by saying 'a user is part of', though it does not explicitly name the alternative.

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

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

Usage is implied by 'a user is part of' and the endpoint, which makes clear this returns sessions for one user. However, there is no explicit guidance on when to use this vs list_ilt_sessions, list_ilt_completions, or other ILT-related siblings, and no prerequisites are stated.

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=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: results are unpaged and a large LMS returns every user, plus the returned fields are limited to id and username. It stops short of noting performance or auth implications of an unbounded result set.

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 what is returned and what is not paged. The trailing endpoint path is mildly redundant but compact; nothing else wastes 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?

No output schema exists, and the description compensates by naming the exact return fields (id and username only) and the unpaged result volume. Combined with a fully documented single parameter and annotations, an agent has everything needed 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?

Schema description coverage is 100% and the single parameter is enum-constrained with its default documented in the schema. The description restates the three status values but adds no syntax or edge-case meaning beyond that, so the 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?

States a specific verb and resource (list LMS users) and pins down the return scope: id and username only. It explicitly names the sibling axislms_search_users as the tool for a different need, so an agent can distinguish the two 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?

Gives the condition for using it (full enumeration by active/inactive/all) and an explicit alternative with its own condition (names, emails, filters -> axislms_search_users). The division of labor is unambiguous.

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, destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds two useful pieces of non-annotated context - the enrollment precondition (a common failure mode) and the fact that attendance can roll up into completion - but says nothing about permission requirements or what happens to a previously recorded mark, which matters for a destructive write.

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 plus the path, with the WRITE marker and the core action front-loaded. The raw endpoint string is somewhat redundant, though it does convey the ID hierarchy cheaply.

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 five-parameter destructive mutation with no output schema and no parameter descriptions, the definition covers the what and the enrollment precondition but not the ID hierarchy, permission model, or how re-marking an existing attendance behaves. Adequate to invoke, not adequate to invoke confidently.

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?

All five parameters are self-describing names and the enum for attendance is already enforced by the schema. The endpoint path does hint at the nesting order (program { program_id }, session { session_id }, meeting { meeting_id }, user { user_id }), but the description never explains that hierarchy or whether the IDs must be consistent with one another - and schema description coverage is 0%.

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 (mark) plus a specific resource (ILT meeting attendance) and its two terminal states. The 'WRITE:' prefix and the explicit endpoint contrast cleanly with read-oriented siblings such as axislms_list_ilt_meetings and axislms_ilt_report.

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 states a concrete prerequisite: 'The user must already be enrolled in the meeting,' which effectively routes the agent to axislms_enroll_user_in_ilt_session when enrollment is missing. It stops short of explicitly naming that sibling or of saying when not to use this tool (e.g., for course or learning-path completion).

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, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds the 'WRITE' prefix, the concrete HTTP DELETE endpoint, and the membership precondition, but says nothing about whether removal revokes derived enrollments or how errors are surfaced.

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 short sentences, front-loaded with the 'WRITE:' classification so the agent sees the mutation risk immediately. The endpoint string is somewhat redundant with the tool name but does double duty as parameter documentation.

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 two-parameter mutation with no output schema and 0% schema description coverage, the definition covers the action and the path binding but leaves error behavior, side effects, and return value entirely unstated. Adequate to invoke, thin for deciding consequences.

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 bare integer properties carry no meaning on their own. The REST path template '/usergroups/members/{usergroup_id}/{user_id}/' documents both parameters and their roles/order, which is a real contribution, but no format or constraint detail beyond that.

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 ('remove a user from a usergroup') and adds the precondition 'they are a member of', which distinguishes it from sibling mutation tools like axislms_add_usergroup_member or axislms_create_usergroup. It does not explicitly name an alternative tool, so it falls short of a 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?

The only usage signal is the implicit precondition that the user must already be a member. There is no guidance on when to use this versus unenrolling a user from a course/learning path, nor any statement about what happens if the membership does not exist.

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 read-only, non-destructive, open-world behavior, so safety is covered. The description adds meaningful context beyond that: it returns personal data, and it discloses the underlying endpoints (GET /users/all/ or /users/filtered/) and paging shape. It omits rate limits or permission requirements, keeping 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?

It is two short sentences with the core purpose front-loaded, followed by a PII warning and endpoint detail. The endpoint parenthetical is slightly opaque but not wasteful; nothing needs to be cut.

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 says it returns the fields requested and warns of personal data, which is enough to call it correctly. The only real gap is that it does not clarify its relationship to axislms_list_users, but for a three-parameter search tool the invocation context is otherwise 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 100%, so the schema already fully documents page, fields, and user_filter syntax. The description adds only a concrete filter example and a loosely worded field-selection note, duplicating rather than extending the schema's detail; 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?

It states a specific verb+resource ('Page through all users' / search with a phrase) and adds field-selection and paging scope, so an agent can tell it is a filtered user listing with chosen fields. It stops short of naming sibling tools; distinction from axislms_list_users and axislms_get_user is left implicit.

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 two modes (all users vs filtered users) imply when the tool is useful, and the example phrase shows the filter form. However, it never states when to prefer this over axislms_list_users or axislms_get_user, nor any when-not condition.

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, readOnlyHint=false and non-idempotent, so the safety profile is covered; the description still adds the concrete consequence ('the user loses access to the course') and the underlying DELETE endpoint. It does not say whether enrollment history/completion records are retained or what happens if the user is not enrolled.

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 a 'WRITE:' marker, each carrying distinct information (action, effect, endpoint). Nothing 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?

For a two-parameter mutation with rich annotations and no output schema, the description covers action, effect, and endpoint adequately. Missing pieces are secondary: permission requirements and behavior on invalid/already-removed enrollments.

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%, but both required parameters are self-describing integer IDs and the path template '/courses/enrollments/{course_id}/{user_id}/' confirms their roles and ordering. No additional format, constraint, or lookup guidance is provided, so it only marginally 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 and resource ('remove a user from an online course'), and the qualifier 'online course' implicitly separates it from the ILT-session and learning-path unenroll siblings. It stops short of naming those siblings explicitly, so an agent must infer the boundary.

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 explicit when-to-use/when-not-to-use guidance and no mention of when to prefer axislms_unenroll_user_from_ilt_session or axislms_unenroll_user_from_learningpath. Usage is only implied by the resource 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description's 'WRITE:' label and DELETE verb add the HTTP method detail, but it does not disclose downstream effects such as what happens to attendance records, whether the removal is reversible, or whether it errors when no enrollment exists. With annotations carrying the safety burden, this is adequate but thin.

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 short sentences, front-loaded with the operation type and verb, with zero filler. The endpoint string is partially redundant with the annotations' destructive/write signals but still earns its place by encoding parameter order.

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 should cover outcomes and failure modes for a destructive, non-idempotent write — it does not. An agent knows what the call does and which IDs to supply, but not what success returns, whether retries are safe (idempotentHint=false implies not), or what preconditions exist.

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. The URL template 'DELETE /ilt/enrollments/{program_id}/{session_id}/{user_id}/' does map each of the three required parameters to a path segment and implies they are positive integer IDs, which is genuine added meaning. However it says nothing about ID provenance (e.g., where to obtain session_id) or error behavior for bad IDs.

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 ('remove') and resource ('a user from a session of an ILT program'), which cleanly separates it from the sibling unenroll_user_from_course and unenroll_user_from_learningpath by naming the ILT session scope. The REST endpoint reinforces the exact resource path. It stops short of an explicit 'this is not the course/learning-path unenroll' statement, so it is clear but not maximally differentiated.

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 on when to use this versus axislms_unenroll_user_from_course, axislms_unenroll_user_from_learningpath, or axislms_remove_usergroup_member. Nothing says whether the user must currently be enrolled, whether prerequisites/approvals matter, or what happens on a non-enrolled user.

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, idempotentHint=false, and readOnlyHint=false; the description mostly restates this with 'WRITE' and the DELETE endpoint. It usefully clarifies that only the learning-path enrollment is removed rather than the user, but says nothing about whether progress is lost, what permissions are required, or whether the removal is reversible. With annotations carrying the safety profile, this is adequate but thin.

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 compact sentences, front-loaded with the operation and followed by the endpoint. No filler; every element is 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 a simple two-ID destructive write with no output schema, and annotations cover safety hints. Still, for a destructive operation the description omits side effects such as enrollment/progress data loss and permission requirements, so it is 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?

Schema description coverage is 0%, so the description must compensate. It only places learningpath_id and user_id in an endpoint template, adding no source, format, or constraint information beyond the property names already present 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 states a specific verb ('remove') and resource ('a user from a learning path'), and includes the exact DELETE endpoint. It clearly distinguishes itself from the sibling enroll_user_in_learningpath by the direction of the 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?

The phrase 'they are enrolled in' implies a precondition, but the description gives no explicit when-to-use guidance, no when-not-to-use guidance, and does not name alternatives such as unenroll_user_from_course or unenroll_user_from_ilt_session. Usage is only implied.

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, destructiveHint=true, and idempotentHint=true, so the safety profile is covered. The description still adds real value beyond them: partial-update semantics (only sent fields change) and the constraint that an empty value is not sent, so a field cannot be cleared here. It does not mention permission requirements for role/manager changes, which is the remaining gap.

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 'WRITE:' and the verb, with the partial-update caveat packed into a parenthetical. No filler or repetition of the title.

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 31-parameter mutation with no output schema, the definition covers update semantics but leaves out permission requirements, the meaning of the custom fields, and any indication of the response. Adequate but with clear gaps given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is only 13% across 31 parameters, so most fields (custom1 through custom15, address fields, first_name, etc.) have no meaning documented anywhere. The description compensates by explaining partial-update behavior, which is the single most important parameter semantic here, but it adds nothing about the custom fields or the role/manager implications. A 3 reflects that partial compensation.

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 gives a specific verb ('change profile fields') and resource ('an existing user'), which cleanly separates it from axislms_create_user and axislms_get_user. It also names the underlying endpoint, PUT /users/{user_id}/. It stops short of explicitly naming the sibling tools it must be distinguished from, 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?

The 'WRITE:' prefix and the note that it edits personal data and can change role or manager imply a mutation context, but there is no explicit statement of when to reach for this tool instead of axislms_create_user or axislms_get_user, and no stated prerequisites. Usage is implied 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 declare it a safe read (readOnlyHint, destructiveHint false), and the description adds real context on top: PII sensitivity ('Contains personal data') and pagination behavior ('paged, 100 per page'). The endpoint path is a useful bonus, though return shape and rate-limit behavior remain undisclosed.

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 the core resource before enumerating kinds and constraints. The trailing endpoint path is slightly technical filler but doesn't bloat the 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 six-param read tool with annotations but no output schema, the description covers the essential dimensions: what kinds exist, scope mechanics, pagination, and PII sensitivity. count_only and page are left to the schema, which documents them adequately, so nothing critical is missing.

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 83% schema coverage the baseline is 3, but the description genuinely adds meaning by glossing each kind ('courses (status, progress, score, dates)', 'archived (archived and imported course results)') and mapping the scope values to user/all/filtered intent. That extra semantics lifts it above the schema-only baseline.

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 resource (a learner's records across the LMS) and enumerates the five kinds plus the three scopes, so an agent knows exactly what it retrieves. It doesn't explicitly name which sibling report tool to prefer (certification_report, course_report), leaving that differentiation implicit.

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 scope enumeration ('for one user, for all users, or for users matching a search phrase') implies when each mode applies, and the schema backs it with scope descriptions. But there's no explicit guidance on when to pick this over the sibling axislms_certification_report / axislms_course_report tools, so usage stays inferred rather than stated.

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