Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Litmos MCP Assign the Code of Ethics course to Jane Smith"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that enables Claude Desktop to interact with the Litmos REST API.
Node.js 18+
Claude Desktop
A Litmos API Key
Related MCP server: Canvas LMS MCP Server
Clone the repository:
git clone <repository-url>
cd Litmos_MCPInstall dependencies:
npm installBuild the project:
npm run buildOpen:
Claude Desktop → Settings → Developer → Edit Config
Add the following configuration:
{
"mcpServers": {
"litmos": {
"command": "node",
"args": [
"C:\\Path\\To\\Litmos_MCP\\dist\\index.js"
],
"env": {
"LITMOS_API_KEY": "<YOUR_API_KEY>",
"LITMOS_BASE_URL": "https://api.litmoseu.com"
}
}
}
}Replace:
C:\\Path\\To\\Litmos_MCP\\dist\\index.js with the full path to your local project.
<YOUR_API_KEY> with your own Litmos API key.
EU customers:
https://api.litmoseu.comUS customers:
https://api.litmos.comRestart Claude Desktop after saving the configuration.
Search for cybersecurity courses.
Show training progress for john.doe@company.com.
Assign the Code of Ethics course to Jane Smith.
Register John Doe to the next available ILT session.
Show all users enrolled in a learning path.
Never commit or share your API key.
API credentials are loaded from environment variables only.
Assign a Litmos course to a single user. For multiple users, use bulk_assign_course_to_users instead.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The Litmos user ID | |
| courseId | Yes | The Litmos course ID to assign |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a write operation ('Assign') but does not disclose prerequisites, authentication requirements, error handling, or side effects. For a simple assignment tool, the basic behavior is clear, but additional context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first states the primary purpose, and the second provides an exclusionary usage guideline. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter structure and no output schema, the description is largely complete. It covers purpose, scope, and usage guidelines. However, it omits any mention of the return value or confirmation of the assignment, which would be helpful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions ('The Litmos user ID', 'The Litmos course ID to assign'). The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign'), the resource ('a Litmos course'), and the scope ('to a single user'). It also distinguishes from the sibling tool 'bulk_assign_course_to_users' by explicitly mentioning the alternative for multiple 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?
The description explicitly states when not to use this tool ('For multiple users') and directs to the alternative ('use bulk_assign_course_to_users instead'). This provides clear guidance for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign a Litmos learning path to a specific user. Checks first if already assigned and returns current progress if so.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The Litmos user ID | |
| learningPathId | Yes | The Litmos learning path ID to assign |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It reveals the idempotent nature and return of progress, but lacks details on side effects, permissions, or error cases. Adequate but not exhaustive.
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 concise at two sentences, front-loading the main action. No unnecessary words; every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema), the description covers the core behavior. It mentions the return of progress but not the format. Sufficient for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds context about the operation (idempotent check) but does not enhance parameter meanings beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Assign' and identifies the resource 'learning path' and target 'user'. It distinguishes from sibling tools like assign_course_to_user by specifying the resource type. The mention of checking if already assigned adds clarity.
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 implicitly provides guidance by stating the idempotent behavior (checks if already assigned and returns progress). However, it does not explicitly state when not to use it or compare with alternatives like bulk_assign_course_to_users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign a course to a list of users. Use this when registering or enrolling multiple users into a course — do NOT call assign_course_to_user repeatedly. Respects the Litmos rate limit automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| userIds | Yes | List of Litmos user IDs to assign the course to | |
| courseId | Yes | The Litmos course ID to assign |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds one behavioral trait (rate limit handling) but lacks detail on other behaviors like idempotency, error handling, or partial success. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Key information is front-loaded: first sentence states purpose, second gives usage directive and behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 required params and no output schema, the description covers purpose and usage sufficiently. Lacks details on return values or errors but is adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (courseId, userIds) with descriptions. The tool description adds no additional semantic meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Assign a course to a list of users' with a specific verb and resource, and explicitly distinguishes itself from the sibling tool 'assign_course_to_user' by advising not to call it repeatedly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('when registering or enrolling multiple users into a course') and what not to do ('do NOT call assign_course_to_user repeatedly'), plus a behavioral note about respecting rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update up to ~2000 users in one job, and/or bulk-enroll existing users into courses. Use course1–course3 fields with the CourseCodeForBulkImport to assign courses to many users at once without touching their other profile data. Username is the unique key — existing users are updated, new ones are created. Unspecified fields are left unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| users | Yes | List of users to create or update. Username is the unique key — existing users are updated, new ones are created. | |
| sendMessage | No | Send login invitation emails to new users (default false) | |
| skipFirstLogin | No | Skip the first-login setup screen (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: up to 2000 users, upsert semantics based on username, and that unspecified fields are left unchanged. It also covers bulk enrollment. However, it lacks details on potential side effects (e.g., email sending when sendMessage is true), error handling, or rate limits. Since annotations are absent, the description could be more comprehensive.
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 concise with four sentences, each adding essential information. It front-loads the main purpose, then explains key behaviors without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality well but does not explain the return value or error responses (no output schema). It also does not reference sibling tools or provide context on when to use this vs. other bulk operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so baseline is 3. The description adds value by explaining the use of course fields with CourseCodeForBulkImport and reiterating the uniqueness of username, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates up to ~2000 users and/or bulk-enrolls existing users into courses. It distinguishes from sibling tools like assign_course_to_user or bulk_assign_course_to_users by focusing on user creation/update with optional course enrollment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides guidance on using course1–course3 fields with CourseCodeForBulkImport, explains that username is the unique key, and specifies that existing users are updated while new ones are created. However, it does not explicitly state when to use this tool versus alternatives like search_users or get_user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register up to 25 users to an ILT session in a single API call. Provide a list of user IDs plus the course, module, and session IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| userIds | Yes | List of Litmos user IDs to register (max 25) | |
| courseId | Yes | The Litmos course ID | |
| moduleId | Yes | The ILT module ID within the course | |
| sessionId | Yes | The session ID to register users for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states it's a single API call and the user limit, but does not disclose side effects (e.g., notifications, idempotency, partial failures) or prerequisites (e.g., user enrollment in course). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It efficiently communicates the core functionality and requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, it does not describe return values (e.g., success indicators, error details). For a bulk operation involving up to 25 users, this is a significant gap. The description is too minimal to be 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 100%, so each parameter is already well-described in the schema. The description merely repeats the parameters and the max limit, adding no new semantic meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers up to 25 users to an ILT session in a single API call, specifying the verb (register), resource (users to session), and constraints (max 25). This clearly distinguishes it from siblings like register_user_to_session or bulk_assign_course_to_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?
The description implies use for batch operations, but lacks explicit guidance on when to use this versus alternatives (e.g., register_user_to_session). No prerequisites or exclusions are mentioned, though the sibling list provides context. The guidance is adequate but not strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for multiple users at once by providing a list of names or emails. Runs all searches in parallel and returns results per query.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | List of search terms (names or emails) to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses parallel execution and per-query results. However, missing details on rate limits, authentication needs, or partial failure 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 concise sentences, front-loaded with action and input, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter, no output schema, and no annotations, description covers input format, parallel behavior, and output structure. Missing error handling or limits, but acceptable for a search 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 has 100% coverage with parameter description. Tool description adds meaning: parallel execution and returns per query, which goes beyond schema. Baseline 3, plus extra context warrants 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'search', resource 'users', and specifies input as 'names or emails'. Behavior (parallel execution, results per query) distinguishes from siblings like 'search_users' (single search) and 'get_user' (by ID).
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?
Implied usage: when you have multiple queries. No explicit when-to-use or when-not-to-use compared to alternatives like 'search_users' (single search) or 'get_user' (exact ID). Lacks exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the same module result for multiple users in parallel. Provide a list of user IDs plus the score, completed flag, and optional note. Returns a per-user success/failure summary.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional note (max 255 characters) | |
| score | Yes | Score (0–100). Typically 100 when marking a module complete. | |
| userIds | Yes | List of Litmos user IDs to update | |
| courseId | Yes | The Litmos course ID the module belongs to | |
| moduleId | Yes | The module ID to record results for | |
| completed | Yes | Set to true to mark the module as completed, false otherwise. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions parallel execution and returns per-user summary but does not disclose atomicity, error handling, rate limits, or authorization requirements. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then inputs and output description. No extraneous information—every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions returns per-user success/failure summary. For a bulk operation with 6 parameters, it covers essential input and output expectations. Minor gap: no mention of error handling or concurrent behavior, but sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value with the score guidance ('Typically 100 when marking a module complete') and clarifies that note is optional. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (record the same module result for multiple users in parallel), specific verb+resource, and distinguishes from siblings like update_module_progress (single user) and bulk_assign_course_to_users (different action).
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 explains what to provide (list of user IDs, score, completed flag, optional note) but does not explicitly state when to use this tool vs alternatives like update_module_progress for single users. Usage context is implied but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an ILT session complete and record attendance in one call. Runs rollcall and attendance marking in parallel for a list of users.
| Name | Required | Description | Default |
|---|---|---|---|
| users | Yes | List of users with their completion status. Score is always recorded as 0. | |
| attended | Yes | true = attended, false = did not attend | |
| courseId | Yes | The Litmos course ID | |
| moduleId | Yes | The ILT module ID within the course | |
| sessionId | Yes | The session ID to mark complete | |
| sessionDayId | Yes | The session day ID to mark attendance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses parallel execution of rollcall and attendance marking, but lacks details on error handling, rollback behavior, or permissions. No annotations provided to offset gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main purpose. No wasted words; efficient and clear.
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?
Adequate for a straightforward write operation with 6 required params and no output schema. Could mention return value or success indication, but not 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?
100% schema coverage with descriptions for all parameters. Description adds no extra meaning beyond schema; baseline score of 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?
Description specifies verb 'Mark an ILT session complete' and resource 'ILT session', with clear action 'record attendance'. Distinguishes from sibling tools like 'register_user_to_session' and 'reset_session_score'.
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?
Implied usage for completing sessions and recording attendance, but no explicit guidance on when to use vs alternatives like 'update_module_progress' or 'bulk_register_users_to_session'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new ILT session within a course module. Supports single or multi-day sessions with optional location, time zone, seat limit, and wait list.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | List of session days | |
| name | Yes | Session name | |
| slots | No | Maximum number of seats | |
| endDate | No | Session end date (YYYY-MM-DD) | |
| courseId | Yes | The Litmos course ID | |
| location | No | Location of the session | |
| moduleId | Yes | The ILT module ID within the course | |
| timeZone | No | Time zone (e.g. 'UTC', 'America/New_York') | |
| startDate | No | Session start date (YYYY-MM-DD) | |
| sessionType | Yes | Session type: 1=Classroom, 2=Virtual, 3=Blended, 4=Other | |
| enableWaitList | No | Allow users to join a wait list when full | |
| instructorName | No | Display name of the instructor | |
| instructorUserId | Yes | Litmos user ID of the instructor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries all behavioral disclosure burden. It mentions supporting multi-day sessions and optional features like seat limit and wait list, but does not disclose permissions required, side effects (e.g., if session creation triggers notifications), or how the system handles multiple days. It provides adequate but not rich behavioral 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?
Two sentences, front-loaded with purpose. Every word adds value, no redundancy. Efficiently conveys core functionality and supported optional features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema), the description is incomplete. It does not mention what the tool returns (e.g., session ID) nor any post-creation behavior. For a creation tool, this omission is significant. Sibling tools like 'register_user_to_session' provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in the schema. The description adds a high-level summary of supported features but does not add meaning beyond what the schema already provides for each parameter. Baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'ILT session within a course module', which distinguishes it from sibling tools like 'register_user_to_session' or 'complete_session'. It also mentions specific capabilities (single/multi-day, optional fields).
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 alternatives. It does not mention prerequisites (e.g., course and module must exist) or when not to use it (e.g., if only single-day, or if using different session types). The context is clear but lacks exclusionary details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific Litmos course by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| courseId | Yes | The Litmos course ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose what 'full details' includes, potential side effects, auth requirements, or rate limits. The description is vague about the scope of returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. However, it lacks structure such as bullet points or front-loaded key details.
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, and the description does not explain the return format or what 'full details' entails. The agent may not know what data to expect, which is a significant gap for a simple retrieval 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 description merely restates the schema description ('The Litmos course ID') without adding new meaning or usage context. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (get), resource (full details for a specific course), and method (by ID). However, there is a sibling tool named 'get_course_details' with nearly identical purpose, and the description does not differentiate between 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?
No guidance is provided on when to use this tool versus alternatives like 'search_courses' or 'get_course_details'. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get extended details for a specific Litmos course (description, tags, custom fields, etc.) by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| courseId | Yes | The Litmos course ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions returned fields but lacks disclosure of side effects, authentication needs, rate limits, or limitations. For a read operation, minimal behavioral 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?
Single sentence, 16 words, front-loaded with verb and resource. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 1 param and no output schema. Description covers purpose and key return fields. Could list all fields or mention comprehensive details, but adequate for the 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?
Only one parameter courseId, schema already describes it as 'The Litmos course ID'. Description adds no extra meaning beyond 'by its ID'. Schema coverage 100% 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?
Clearly states verb 'Get', resource 'extended details for a specific Litmos course', and specifics like description, tags, custom fields. Distinguishes from sibling tools like get_course and search_courses by emphasizing 'extended details'.
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?
Implied usage for getting extended details of a course by ID, but no explicit when-to-use, when-not-to-use, or alternatives. Sibling get_course exists but no differentiation provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all modules inside a specific Litmos course, including module type and completion status.
| Name | Required | Description | Default |
|---|---|---|---|
| courseId | Yes | The Litmos course ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it lists modules with type and completion status, but lacks details on visibility, pagination, or permissions. For a simple listing tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the essential action and output. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the core functionality. It could mention if all modules are returned or any ordering, but it is sufficiently complete for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (courseId) described in the schema. The description adds minimal value beyond restating the tool's purpose; it does not elaborate on the parameter's format or 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?
The description uses a specific verb ('list') and resource ('modules inside a specific Litmos course'), and mentions the included details (module type, completion status). It clearly distinguishes from sibling tools like get_course or update_module_progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when module details are needed but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all users enrolled in a specific Litmos course, including their completion status and progress.
| Name | Required | Description | Default |
|---|---|---|---|
| courseId | Yes | The Litmos course ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It indicates a read operation (get) and mentions return fields (completion status, progress), but does not explicitly state it is read-only, nor disclose pagination, rate limits, or any side effects. Basic but lacking depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys purpose and key detail without waste. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description hints at return fields (completion status, progress) which is helpful. However, it lacks details on pagination, field structure, or example. Still mostly complete given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'courseId', and the schema description already explains it. The tool description adds no additional semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all users enrolled in a specific Litmos course, including completion status and progress. It uses a specific verb ('Get') and resource ('users') and distinguishes from sibling tools like 'get_user' (single user) or 'search_users' (search across courses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving enrolled users, but does not state when not to use it or provide context for choosing among siblings like 'get_user_training' or 'search_users'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific Litmos learning path by its ID, including name, description, and active status.
| Name | Required | Description | Default |
|---|---|---|---|
| learningPathId | Yes | The Litmos learning path ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the operation is a read (get details) and mentions returned fields. However, it does not describe error scenarios, authentication needs, or response format. Adequate for a simple retrieval but could be more explicit.
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?
Single sentence, front-loaded with the verb 'Get details', efficient and free of unnecessary words. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and simple functionality, the description lists key fields (name, description, active status) which provides reasonable completeness. Could mention what is returned if ID not found, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description does not add any meaning beyond what the schema already provides (learningPathId with description). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details for a specific learning path by ID, listing fields like name, description, and active status. It distinguishes the resource (learning path) from siblings, but does not explicitly differentiate from get_learning_path_users or other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_course or get_learning_path_users. No prerequisites, context, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all users enrolled in a specific Litmos learning path, including their completion status and progress.
| Name | Required | Description | Default |
|---|---|---|---|
| learningPathId | Yes | The Litmos learning path ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It correctly describes a read operation (get) but does not mention safety traits like read-only, authentication needs, or rate limits. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It efficiently conveys the tool's purpose and key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, the description is largely complete. It specifies the resource (learning path), the population (users), and the data returned (completion status and progress). However, it does not mention return format or pagination, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and the description of learningPathId in the schema is clear. The tool description does not add additional meaning beyond what the schema provides, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all users enrolled in a specific Litmos learning path, including completion status and progress. This is distinct from sibling tools like get_course_users or get_learning_path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly discuss when to use this tool versus other related tools, nor does it provide exclusionary guidance. However, the purpose is clear enough that an agent can infer its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ILT (Instructor-Led Training) sessions available for a specific module within a course.
| Name | Required | Description | Default |
|---|---|---|---|
| courseId | Yes | The Litmos course ID | |
| moduleId | Yes | The ILT module ID within the course |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does not disclose whether the operation is read-only, the nature of the output, or any side effects. For a list operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the purpose. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the return value contains. It does not specify whether it returns a list of session IDs, full session objects, or any pagination details, leaving a significant 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 coverage is 100% and both parameters have clear descriptions. The tool description adds minimal extra context (e.g., 'ILT') beyond what the schema already provides, so it meets baseline but does not enhance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ILT sessions for a specific module within a course, using a specific verb and resource. It distinguishes from sibling tools like create_session, complete_session, and register_user_to_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only implies the need for courseId and moduleId but does not mention prerequisites or cases where other tools are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full profile details for a specific Litmos user by their ID.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The Litmos user ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the basic operation (get full profile by ID) but omits behavioral traits such as authorization needs, error handling (e.g., if user not found), or output format 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 a single sentence with no superfluous words. It efficiently conveys the core purpose and input requirement.
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 retrieval tool with one parameter and no output schema, the description covers the basics. However, it lacks details on what 'full profile details' includes and does not mention error or edge cases, leaving some ambiguity.
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% with the property description 'The Litmos user ID'. The description adds 'full profile details' but does not enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'full profile details for a specific Litmos user', and the identifier 'by their ID'. It is specific and distinguishable from siblings like 'search_users' and 'assign_course_to_user', though it does not explicitly contrast 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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. It only states the input requirement without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's full training record: all assigned courses and learning paths with completion status and progress percentages.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The Litmos user ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves a full training record with completion status and progress, implying read-only behavior. However, it does not mention pagination, filtering options, or any rate limits, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. Every word earns its place, and there is no redundancy or unnecessary 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?
Given the low complexity (1 parameter, no output schema, no nested objects), the description is reasonably complete. It covers the purpose and what is returned. Minor omission: it does not mention any limitations like active vs. archived training, but overall it suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'userId' described as 'The Litmos user ID'. The description adds meaning by explaining that the tool returns all assigned courses and learning paths, which goes beyond the schema. Thus it provides moderate added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'user's full training record', and specifies what it includes (all assigned courses and learning paths with completion status and progress percentages). This distinguishes it from sibling tools like 'get_user' or 'assign_course_to_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 description does not provide guidance on when to use this tool versus alternatives such as 'get_course' or 'get_learning_path'. It implies retrieval context but lacks explicit when/when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a Litmos user to a specific ILT session within a course module.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | The Litmos user ID to register | |
| courseId | Yes | The Litmos course ID | |
| moduleId | Yes | The ILT module ID within the course | |
| sessionId | Yes | The session ID to register for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It does not disclose side effects, prerequisites (e.g., user enrollment), or behavior on duplicate registration.
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?
Single, front-loaded sentence with no wasted words. Efficiently conveys the core purpose.
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?
Lacks return value, error conditions, and context like idempotency. Incomplete for a mutation tool with no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters (100% coverage). The description adds no additional meaning beyond 'register a user', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Register'), the resource ('Litmos user to a specific ILT session within a course module'), and distinguishes from sibling tools like assign_course_to_user or complete_session.
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 tool versus alternatives like bulk_register_users_to_session. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset the score to 0 for a list of users in a session, while preserving their current completed status.
| Name | Required | Description | Default |
|---|---|---|---|
| users | Yes | List of users. Pass each user's current completed status — score will be forced to 0. | |
| courseId | Yes | The Litmos course ID | |
| moduleId | Yes | The ILT module ID within the course | |
| sessionId | Yes | The session ID to reset scores for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that only the score is reset and completed status is preserved, but it does not mention side effects, permissions needed, rate limits, idempotency, or what happens if users are not found. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and the key constraint. Every word is necessary; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters, no output schema, and no annotations, the description covers the core behavior and the critical nuance (preserving completed status). It is complete enough for an agent to understand what the tool does and how to use it, though additional context on return values or error cases would improve completeness.
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 description adds 'list of users' but largely repeats the schema's own parameter descriptions (e.g., 'Pass each user's current completed status — score will be forced to 0.'). The description adds minimal new meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reset the score to 0'), the resource ('for a list of users in a session'), and the key nuance ('preserving their current completed status'). This distinguishes it from sibling tools like update_module_progress, which may modify progress but not specifically reset scores.
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 this tool (when needing to reset scores while preserving completion status), but it does not explicitly state when not to use it or mention alternatives. Among sibling tools, update_module_progress could be a related alternative, but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Litmos courses by name or keyword. Returns a list of matching courses with their IDs, names, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (1–100, default 20) | |
| query | Yes | Search term for course name or keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It describes output structure but does not mention pagination, ordering, or that limit parameter controls result count. Basic transparency but lacks detail.
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?
Single sentence conveys purpose and output with no wasted words. Well-structured and 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 search tool with no output schema, description adequately states what is returned. Could mention pagination behavior but not essential given limit parameter. Completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds little beyond schema. Both parameters are documented in schema; description merely restates that search is by name or keyword, not adding new semantic 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?
Description clearly states it searches courses by name or keyword and returns a list with IDs, names, and status. It distinguishes from sibling tools like get_course (single course) but does not explicitly differentiate from get_course_details.
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 tool vs alternatives like get_course or get_course_details. Does not specify prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Litmos users by name or email address. Returns a list of matching users with their IDs and profile details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (1–100, default 20) | |
| query | Yes | Search term (name or email) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only states functionality, but omits details on matching behavior (partial, case-insensitive), pagination, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 18 words, efficiently conveying purpose and return value. No extraneous 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?
Adequate for a simple search tool with two parameters. Lacks details on return format structure, sorting, pagination, or error conditions. Without output schema, more specificity would help.
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%, baseline 3. Description adds 'by name or email' but doesn't go beyond schema's description for either parameter. No additional parameter-level details or examples.
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?
Clearly states it searches for Litmos users by name or email, returning matching users with IDs and profile details. Distinguishes from siblings like get_user (specific user) and search_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage when needing to find users by name or email, but no explicit guidance on when not to use or alternatives. Sibling tools like bulk_search_users and get_user exist but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a module result for a user: set score (0–100), mark as completed or not, and optionally add a note. Uses the Litmos /results/modules API.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional note (max 255 characters) | |
| score | Yes | Score (0–100). Typically 100 when marking a module complete. | |
| userId | Yes | The Litmos user ID | |
| courseId | Yes | The Litmos course ID the module belongs to | |
| moduleId | Yes | The module ID to record results for | |
| completed | Yes | Set to true to mark the module as completed, false otherwise. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions using the Litmos API but does not disclose whether the operation is destructive (overwrites previous results), its idempotency, required authentication, or rate limits. The description lacks behavioral details beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words. The first sentence front-loads the core purpose and parameters, the second adds API context. Every sentence contributes to understanding.
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 annotations are absent. The description lacks return value information, error handling, and clarification on whether this creates or updates progress. For a mutation tool with 6 parameters, more detail is needed to use 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%, so baseline is 3. The description adds value by noting 'Typically 100 when marking a module complete' and clarifying that the note is optional. This provides practical context not present in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Record' and identifies the resource 'module result'. It lists the key actions: set score, mark completed, add note. This clearly distinguishes it from sibling tools like 'bulk_update_module_progress' which is for batch operations.
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 vs. alternatives. For example, it does not mention that 'bulk_update_module_progress' should be used for updating multiple users or modules at once, nor does it provide context about prerequisites (e.g., user must be enrolled in course).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0assign_course_to_userassign_learning_path_to_userbulk_assign_course_to_usersbulk_import_usersbulk_register_users_to_sessionbulk_search_usersbulk_update_module_progresscomplete_sessioncreate_sessionget_courseget_course_detailsget_course_modulesget_course_usersget_learning_pathget_learning_path_usersget_module_sessionsget_userget_user_trainingregister_user_to_sessionreset_session_scoresearch_coursessearch_usersupdate_module_progressScored across 23 tools
Each tool has a clearly distinct purpose, with bulk variants explicitly separated from single-user operations, and get/search functions differentiated by scope. No tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case, with descriptive prepositions where needed (e.g., assign_course_to_user, get_course_users). No mixed conventions or ambiguous verbs.
23 tools cover the core LMS operations (users, courses, learning paths, ILT sessions, bulk operations) without redundancy. Each tool adds clear value for its domain.
The toolset provides strong read, create, and update capabilities, but lacks delete operations for courses, users, or sessions. Bulk import handles updates but not deletion. This leaves some workflow dead ends.
AI-powered corporate learning platform — manage courses, users, and insights via Claude.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Create, edit, translate, and export SCORM eLearning modules from a connected AI assistant.
