Click on "Install 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., "@ictexam-mcp Show me the item analysis for the last chemistry exam."
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.
A Model Context Protocol server for ICTExam, the AI exam authoring, delivery and auto-grading platform from ICT Innovations.
It lets an AI assistant read your exams, gradebooks and per-question item analysis, and — only when you turn writes on — parse a question paper into a structured exam with AI and publish exams to students.
Run it straight from npm with npx, or install it globally:
npx -y ictexam-mcp # no install
npm install -g ictexam-mcpRequires Node.js 18 or newer.
Related MCP server: Canvas LMS MCP Server
Set these in your MCP client's server config (or a .env):
Variable | Required | Default | |
| yes | Your site, e.g. | |
| yes | A teacher or admin account | |
| yes | Password for that account | |
| no |
| API mount path; set empty to hit the backend port directly |
| no |
| Unlock the write tools (see Safety) |
| no |
| Per-request timeout (AI parsing can be slow) |
| no |
| Skip TLS verification — self-signed test servers only |
{
"mcpServers": {
"ictexam": {
"command": "npx",
"args": ["-y", "ictexam-mcp"],
"env": {
"ICTEXAM_BASE_URL": "https://app.ictlms.net",
"ICTEXAM_EMAIL": "teacher@example.com",
"ICTEXAM_PASSWORD": "your-password"
}
}
}
}Read tools are always available:
Tool | What it does |
| List exam papers (id, title, status, class, subject) |
| One paper's settings, share links and questions |
| Classes (course groups) |
| Subjects, each tied to a class |
| Per-exam totals and student marks |
| Per-question difficulty, p-value and average mark |
Write tools appear only when ICTEXAM_MCP_ALLOW_WRITE=true:
Tool | What it does |
| Upload a local PDF/DOCX and AI-extract the questions |
| Publish a paper; returns student and teacher share URLs |
| Set a paper back to draft |
The server is read-only by default. The three write tools are not registered
at all unless you set ICTEXAM_MCP_ALLOW_WRITE=true, so a default install cannot
change anything on the platform. Parsing a paper spends AI credit on the server,
and publishing makes an exam live for students — both sit behind that switch on
purpose. The client authenticates with the account's own session cookie and
echoes the CSRF token on writes, exactly as the web app does; it never stores or
logs your password beyond the environment you give it.
ICTExam runs a FastAPI backend. The server signs in once with your email and
password, keeps the session cookie for the life of the process, and talks to the
REST API under /api (configurable). No API key to provision.
Built by Tahir Almas at ICT Innovations — the team behind ICTExam, ICTContact, ICTDialer, ICTFax and ICTPBX. ICTExam ships with a native Moodle activity module (LTI 1.3, grade passback and roster sync); learn more at ictlms.net.
MIT licensed. Issues and PRs welcome at github.com/ictinnovations/ictexam-mcp.
Get a single exam paper by id: its settings, timing, share links and questions.
| Name | Required | Description | Default |
|---|---|---|---|
| assessment_id | Yes | The exam paper (assessment) id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as readOnlyHint=true, so the read-only nature is covered. The description adds value by specifying exactly what the response contains (settings, timing, share links, questions), which is particularly helpful since there is no output schema. It does not mention error cases or edge behavior, but the simplicity and annotations lower that need.
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, tight sentence that front-loads the verb and resource, then compactly enumerates the return contents. Every word earns its place, with no repetition or 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 simple get-by-id tool with one required parameter, readOnlyHint=true, and no output schema, the description provides sufficient information for an agent to select and invoke the tool correctly. It states what the tool returns, which is exactly what an agent needs to know in this 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?
The input schema documents the only parameter, assessment_id, with a description saying it is 'The exam paper (assessment) id.' The description's 'by id' merely echoes this without adding new meaning. Since schema description coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a resource ('a single exam paper'), and the selection method ('by id'). It also lists the key contents returned (settings, timing, share links, questions), which makes its function unambiguous. This clearly distinguishes it from sibling tools like ictexam_list_exams, which presumably handles multiple exams.
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 tells the agent when to use this tool: when a single exam paper is needed by its assessment_id. The contrast with list_exams is clear from the wording, but there is no explicit statement such as 'for all exams, use list_exams instead.' This is a minor omission, so it earns a strong 4 but not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the teacher gradebook: per-exam totals and student marks. Optionally filter by class_id or subject_id.
| Name | Required | Description | Default |
|---|---|---|---|
| class_id | No | Optional class id filter. | |
| subject_id | No | Optional subject id filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful context about what data is returned ('per-exam totals and student marks') and the optional filtering, but does not disclose other behaviors such as default scope, data volume, or response shape.
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 main purpose and then states the optional filters. Every word contributes value, with no redundancy or 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 read-only retrieval tool with two optional, well-documented parameters and no output schema, the description adequately states what the tool returns and how to narrow results. It could mention the default behavior when no filters are supplied, but the core information needed to call it correctly 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 100%, so both parameters are fully documented with 'Optional class id filter' and 'Optional subject id filter'. The description repeats this information without adding new semantic detail beyond what the schema already provides, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names a concrete resource ('teacher gradebook') with content ('per-exam totals and student marks'). This is clear and distinct from the sibling tools such as ictexam_list_exams or ictexam_get_exam, though it does not explicitly name a differentiating 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?
The description implies when to use the tool: when gradebook-level data across exams and students is needed. It also indicates the optional filters. However, it provides no explicit guidance on when not to use it or how it compares to siblings like ictexam_get_exam or ictexam_item_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-question item analysis for one exam: difficulty, p-value, average mark and how many responses were full vs zero credit.
| Name | Required | Description | Default |
|---|---|---|---|
| assessment_id | Yes | The exam paper (assessment) id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds valuable behavioral detail by enumerating the computed metrics (difficulty, p-value, average mark, full vs zero credit), which is meaningful because no output schema exists.
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, efficient sentence where the core purpose and output details are front-loaded. There is no redundant content or 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 one-parameter read-only analytics tool, the description sufficiently covers inputs and expected outputs. It could optionally mention ordering or exact response format, but the listed metrics give an agent enough information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter assessment_id is already documented as 'The exam paper (assessment) id.' The description only reinforces this with 'one exam,' adding no new semantic detail 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 identifies the tool as 'per-question item analysis for one exam' and specifies the outputs (difficulty, p-value, average mark, full/zero credit counts). It lacks an explicit verb, but 'Per-question item analysis' plus resource scoping makes the purpose clear and distinguishable from gradebook or listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one exam' provides clear context that this tool is for single-assessment, per-question statistics. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to understand the intended scope versus siblings like gradebook or list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the classes (course groups) defined on ICTExam.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, so the safety and openness profile is covered. The description adds scoping context ('defined on ICTExam') and clarifies the meaning of classes as 'course groups'. It does not contradict the annotations, but it adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the verb and resource immediately and adds a parenthetical clarification ('course groups') that improves comprehension without extra length.
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 parameterless, read-only list tool with a clear name and sibling context, this description is sufficient for an agent to select and invoke it correctly. The return behavior is self-evident from the word 'List', and no additional preconditions or configuration details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the schema already carries all the parameter information. The description does not need to explain parameters, and the baseline of 4 applies here.
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 verb ('List') and a clearly scoped resource ('classes (course groups) defined on ICTExam'). It distinguishes this tool from siblings like ictexam_list_subjects and ictexam_list_exams by naming the resource type explicitly. It is not a tautology of the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use: call when you need the list of class/course groups defined on ICTExam. However, it does not explicitly mention when to prefer it over sibling list tools or when not to use it. Usage is clear from context but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List exam papers (assessments) on ICTExam: id, title, status (draft/published), class and subject. Start here to find an exam's id. Optionally filter by class_id or subject_id.
| Name | Required | Description | Default |
|---|---|---|---|
| class_id | No | Optional class id filter. | |
| subject_id | No | Optional subject id filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds context about the data model (status values draft/published, fields returned) and positions the tool as a discovery mechanism. It does not discuss pagination, ordering, or limits, but these are less critical given the simple read-only nature and proactive annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and returned data, followed by usage guidance and filter options. Every sentence contributes value; there is no fluff or repetition.
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 two optional filters and no output schema, the description is complete: it states the resource, the fields returned, the entry-point role, and the available filters. The annotations cover safety, and no essential call-time information 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 100%: both class_id and subject_id have clear descriptions ('Optional class id filter', 'Optional subject id filter'). The description merely restates 'Optionally filter by class_id or subject_id' without adding new semantics like filter behavior or format requirements. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('exam papers (assessments) on ICTExam'), and specifies the returned fields (id, title, status, class, subject). It also differentiates itself from sibling tools by positioning this as the entry point to find an exam's id, which get_exam likely retrieves by id. This makes the tool's purpose unmistakable.
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 'Start here to find an exam's id' gives clear context for when to use this tool as the first step in a workflow. It does not explicitly name alternatives or state when not to use it, but the guidance is clear enough for a simple list-with-filter tool. Lacking explicit exclusions keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the subjects on ICTExam, each tied to a class.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already tells the agent this is a safe read operation, and the description aligns with that. It adds a small behavioral/data-model detail by noting subjects are tied to classes, but it does not disclose additional behavioral traits such as auth needs or response structure.
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 one short, front-loaded sentence that states exactly what the tool does. Every word earns its place, and there is no redundant 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 zero-parameter, read-only listing tool, the description is nearly complete. It defines the resource and a key relationship to classes, and the annotations cover safety. It does not describe the return shape, but that is a minor gap for such a simple 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?
There are zero parameters, so the empty schema fully covers parameter semantics. With no parameters, the description does not need to compensate for undocumented inputs, and the tool can be invoked without additional 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?
The description uses a specific verb and resource: 'List the subjects on ICTExam.' It also adds a distinguishing detail, 'each tied to a class,' which helps separate this tool from sibling tools like ictexam_list_classes and ictexam_list_exams.
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 guidance on when to use this tool versus the sibling tools. It does not mention alternatives, exclusions, or a decision rule such as 'use this when you need subjects rather than classes or exams.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct entity or artifact: subjects, classes, exams, exam detail, gradebook, and item analysis. There is no pair that would plausibly produce the same result, so an agent can reliably choose based on the desired resource.
All tools share the consistent ictexam_ prefix, and most use a clear verb_noun pattern (list_subjects, list_exams, list_classes, get_exam). However, gradebook and item_analysis are plain noun phrases, breaking the imperative verb pattern.
Six tools is a compact and well-scoped set for an exam data and analytics MCP. Each tool covers a meaningful query surface, and none feels redundant or unnecessary.
The set covers the core read-only workflows: enumerating classes, subjects, and exams; retrieving an exam; viewing gradebook data; and running item analysis. It lacks create/update/delete operations, but those appear outside the apparent analysis-oriented purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only AI access to HAVN properties, leads, tasks, files, media, and analytics.
Connect your Moodle to AI assistants: courses, content, grading and reports from the chat.
Give AI agents secure access to RevDesk calling, SMS, phone numbers, caller IDs, and usage.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ictinnovations/ictexam-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
