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., "@mcp-ignite-server show me my schedule"
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 (MCP) server providing access to Microsoft Ignite 2025 conference data—1,033 sessions, 1,579 speakers, plus your personal schedule and favorites.
Related MCP server: M365 MCP
7 MCP Tools: Search sessions/speakers, get schedules, view favorites, and fetch complete conference data
Smart Caching: Auto-refresh every 15 mins (sessions) and 60 mins (speakers) for fast, reliable access
Personal Data: Full access to your authenticated Ignite schedule and favorites
Production Ready: Tested with Claude Desktop and VS Code
npm install
npm run buildMethod 1: From Cookie (Recommended)
Sign in at https://ignite.microsoft.com
Open DevTools (F12) → Application tab → Cookies → ignite.microsoft.com
Find the cookie named ignite2025.prod.token
Copy the cookie value and prefix it with Bearer (e.g., Bearer eyJhbGc...)
Method 2: Console Script Run this in the browser console on ignite.microsoft.com:
(function () {
const cookies = Object.fromEntries(
document.cookie.split(";").map(c => {
const [k, ...v] = c.split("=");
return [k.trim(), decodeURIComponent(v.join("="))];
})
);
const rawToken = cookies["ignite2025.prod.token"];
if (!rawToken) {
console.warn("ignite2025.prod.token cookie not found");
return null;
}
const bearer = `Bearer ${rawToken}`;
console.log("Bearer token:", bearer);
return bearer;
})();Note: This will only allow the MCP server to function for 1 hour at a time, anyone who knows a good way to enhance this like figuring out if there is a refresh token is welcome to contribute to the library.
Create a .env file:
IGNITE_BEARER_TOKEN=your_token_hereNote: You can also just put this into the mcp env config
⚠️ Never commit your token to version control!
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"ignite": {
"command": "node",
"args": ["/absolute/path/to/mcp-ignite-server/build/index.js"],
"env": {
"IGNITE_BEARER_TOKEN": "your_token_here"
}
}
}
}Create or edit .vscode/settings.json in your workspace:
{
"github.copilot.chat.codeGeneration.instructions": [
{
"text": "Use MCP tools when available"
}
],
"github.copilot.chat.mcp.enabled": true,
"github.copilot.chat.mcp.servers": {
"ignite": {
"command": "node",
"args": ["/absolute/path/to/mcp-ignite-server/build/index.js"],
"env": {
"IGNITE_BEARER_TOKEN": "your_token_here"
}
}
}
}Restart VS Code after adding the configuration.
Tool | Description | Key Parameters |
get_all_sessions | Fetch all 1,033 sessions (cached) |
|
get_session_details | Get specific session info |
|
search_sessions | Find sessions by keyword |
|
get_my_schedule | Your personal schedule | — |
get_favorites | Your favorited sessions/labs | — |
get_all_speakers | Fetch all 1,579 speakers (cached) |
|
search_speakers | Find speakers by keyword |
|
Examples:
"Show me all AI sessions in my schedule"
"Find speakers from Microsoft working on Azure"
"Get details for session BRK123"
Cache files stored in data/:
sessions-cache.json (~8MB, refreshes every 15 min)
speakers-cache.json (~2MB, refreshes every 60 min)
Benefits: instant responses, offline capability, reduced API load.
Uses official Microsoft Ignite API (https://api-v2.ignite.microsoft.com):
/api/session/all/en-US - All sessions
/api/schedule/sessions/en-US - Your schedule
/api/speaker/all/en-US - All speakers
/api/favorite/* - Your favorites
See API_RESEARCH.md for complete documentation.
Issue | Solution |
"IGNITE_BEARER_TOKEN is not set" | Create |
"API request failed: 401" | Token expired—get a fresh one |
"No cached sessions available" | Run |
npm run build # Compile TypeScript
npm run dev # Watch modeMIT
Keep your bearer token secure—never commit or share it
Tokens expire periodically; refresh as needed
Server is read-only; it won't modify your data
Unofficial tool, not affiliated with Microsoft. Use responsibly and respect Microsoft's terms of service.
Fetch all Microsoft Ignite sessions with caching. Cache expires after 15 minutes and will be refreshed on the next request. Use refresh=true to force immediate refresh.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | Force refresh the cache from the API, bypassing the 15-minute cache expiration (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It transparently discloses the caching behavior: 15-minute expiration, automatic refresh on the next request, and the ability to force refresh with refresh=true. This goes beyond a simple fetch and helps the agent understand side effects and timing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The main action is front-loaded, followed by the key behavioral caveat (cache expiration) and the parameter hint. 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?
For a simple tool with one optional parameter, no annotations, and no output schema, the description covers the essential points: what it fetches, caching behavior, and how to override the cache. It does not mention return format or large-result handling, but that is a minor gap for this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single refresh parameter, so the baseline is 3. The description reinforces the same information ('Use refresh=true to force immediate refresh') without adding meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Fetch all Microsoft Ignite sessions' — exactly what the tool does. It is clearly distinguished from siblings like get_session_details (singular) and search_sessions (filtered) by emphasizing 'all'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: this tool is for retrieving the complete set of sessions, as opposed to a single session or a search. It does not explicitly name alternative tools, but the 'all' scope makes the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch all Microsoft Ignite speakers with caching. Cache expires after 60 minutes and will be refreshed on the next request. Use refresh=true to force immediate refresh.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | Force refresh the cache from the API, bypassing the 60-minute cache expiration (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description takes on the burden by disclosing the caching lifecycle and refresh behavior. It explains what happens after expiration and what the refresh flag does, which is meaningful behavioral context beyond the schema. It doesn't mention output structure or potential pagination, but for a simple fetch-all read operation the key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with the core purpose front-loaded, followed by the two essential cache behaviors. Every sentence earns its place and there is no redundant or promotional language.
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 a single optional parameter and no annotations, the description is largely complete: it says what is fetched, how caching behaves, and how to force a refresh. A returned-object shape would be nice given no output schema, but the resource name and 'all speakers' scope provide enough context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the refresh parameter is already documented in the schema as forcing a cache refresh while bypassing the 60-minute expiration. The description's 'Use refresh=true' sentence adds usage emphasis but no new parameter meaning, 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 starts with a specific verb and resource: 'Fetch all Microsoft Ignite speakers.' The word 'all' differentiates it from sibling search_speakers, making the tool's scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance for caching and the refresh parameter: cache expires in 60 minutes, refreshes on next request, and refresh=true forces immediate refresh. It doesn't explicitly name an alternative for filtered speaker queries, but the all-vs-search scope is evident from the description and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all sessions that you have marked as favorites
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that the operation returns only favorited sessions, but it does not mention any additional behavior such as ordering, authentication requirements, or that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words. It front-loads the action and resource while staying immediately understandable.
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, no-output-schema tool of low complexity, the description is largely complete. It identifies the resource and the criterion (favorites), though it could briefly state that no arguments are required or clarify the scope of 'you' relative to the current user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to explain. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies a distinct resource: sessions marked as favorites. This clearly differentiates it from siblings like get_all_sessions and search_sessions based on the favorites filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: retrieve sessions the current user has favorited. However, it does not explicitly state when to prefer this over get_all_sessions or search_sessions, nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all sessions that you have added to your personal schedule
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 but does not mention read-only behavior, authentication requirements, sorting, or what happens when the schedule is empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with no filler. The core action and scope are front-loaded and immediately actionable.
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 retrieval tool, this is essentially complete: it states what is returned and whose schedule is referenced. No output schema exists, but the description reasonably implies the return value is a collection of session objects.
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 no parameters and schema description coverage is 100%, so parameter documentation is not needed. The description adds no parameter meaning because none exist.
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 a clear resource ('sessions that you have added to your personal schedule'), which distinguishes it from siblings like get_all_sessions. The personal scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'personal schedule' clearly indicates this tool returns only the current user's scheduled sessions, implying it should not be used for global session browsing. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Ignite session by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The unique identifier for the session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation via 'Get', which is the primary behavioral trait. With no annotations provided, the description carries the disclosure burden, but it does not mention error behavior, authentication requirements, or what specific details are returned.
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, focused sentence with no filler or redundant content. The core action, resource, and scoping detail are all included efficiently.
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 retrieval tool, the description is adequate and gives the essential purpose. However, with no output schema, it leaves the phrase 'detailed information' unspecified and gives no indication of not-found behavior or response structure, creating a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single sessionId parameter with a clear description. The tool description adds only the 'by its ID' phrasing, which restates the schema without providing additional semantic 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 a specific verb ('Get'), resource ('Ignite session'), and scope ('by its ID'), making it easy to understand what the tool does. It is distinct from sibling list/search tools, though it does not explicitly name 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 implies this tool should be used when you have a session ID and need detailed information about that session. However, it provides no explicit guidance on when to prefer this over alternatives like get_all_sessions or search_sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search sessions by title, description, speaker, or tags
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| filterFavorites | No | Only show favorited sessions | |
| filterScheduled | No | Only show sessions in your schedule |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates the tool searches by certain fields but does not describe match behavior, result scope, filtering semantics, or read-only nature. Some behavior is implied by 'Search', but meaningful context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence conveys the core purpose and searchable fields without wasted words. It is appropriately sized for a straightforward search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter search tool with high schema coverage, the description is minimally viable. However, with no annotations and no usage guidance relative to sibling tools, an agent receives only basic search semantics and no behavioral or return 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 the baseline is 3. The description adds real semantic value by explaining what the query parameter matches against (title, description, speaker, tags), going beyond the generic schema text 'Search query string'.
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 ('Search') and resource ('sessions'), and lists the fields matched: title, description, speaker, or tags. This clearly distinguishes it from sibling tools like search_speakers and get_all_sessions.
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 word 'Search' implies use for targeted lookup rather than listing all sessions, but no explicit guidance is given about when to prefer this over get_all_sessions or search_speakers. There are no exclusions or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search speakers by name or company. Searches firstName, lastName, displayName, and company fields only. Use firstNameOnly or lastNameOnly for precise name matching.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| lastNameOnly | No | Search only in last name field (exact word match) | |
| firstNameOnly | No | Search only in first name field (exact word match) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and it does so by stating the field restriction ('fields only') and the meaning of the precise-matching flags. It does not cover result format, limits, or case sensitivity, but for a read-only search tool it reveals the most decision-relevant 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 sentences, front-loaded with the primary action and scope, followed by targeted parameter guidance. No filler or repetition of schema 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?
For a simple 3-parameter, 100%-schema-covered search tool, the description covers the searchable fields and the semantics of the optional flags, which is enough to invoke it correctly. It omits output shape and pagination, but those are not necessary for selecting and calling the tool and can be inferred from the tool name.
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 by mapping the query to the searchable fields (name/company and the four specific fields) and by clarifying the effect of the boolean flags on matching precision. This goes beyond the schema's raw field 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 opens with a specific verb and resource ('Search speakers') and narrows the scope by listing the exact fields searched (firstName, lastName, displayName, company). This clearly distinguishes it from sibling search_sessions and from get_all_speakers, since it is a targeted search rather than a list-all or session lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context on when to use the tool (finding speakers by name or company) and offers parameter-level guidance for precise matching with firstNameOnly/lastNameOnly. It does not explicitly name alternatives or state when not to use it, but the usage context is unambiguous.
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. Dates show when Glama detected each change.
v2025.0.2get_all_sessionsget_all_speakersget_favoritesget_my_scheduleget_session_detailssearch_sessionssearch_speakersMost tools target clearly different resources: sessions, speakers, favorites, and schedule. get_favorites and get_my_schedule are conceptually similar user-session lists, but their descriptions distinguish favorites from schedule.
All tools follow a consistent verb_noun pattern using get_ or search_ prefixes, with resources and modifiers clear across the set. No casing or verb-style inconsistencies.
Seven tools cover the conference content surface (sessions, speakers, user lists) without redundancy or bloat. The count is well-scoped for a specialized Ignite server.
Core discovery is covered: list/search sessions, get details, list/search speakers, and retrieve personal session collections. The main minor gap is the lack of mutation tools for favorites/schedule, but for a read-only conference data server the surface is functional.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
APIs.guru MCP — keyless directory of 2,500+ public APIs and their OpenAPI specs.
Official Microsoft MCP Server to query Microsoft Entra data using natural language
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Eric2XU/mcp-ignite-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
