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., "@ifc-mcp Open examples/sample.ifc and summarize the model."
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.
IFC MCP lets your AI assistant inspect IFC/BIM files, create IFC files, create reports, open IFC models in a viewer, and apply BCF viewpoints.
After installation, ask your AI client in normal language. The AI client starts IFC MCP when it needs the IFC tools and sends your request to the local server. IFC MCP reads IFC files locally, runs the needed IFC logic in a local Pyodide runtime with IfcOpenShell, and returns the answer to the chat.
Good example prompts:
Open examples/sample.ifc and summarize the model.
Count the walls, doors, windows, spaces, and property sets in examples/sample.ifc.
Find missing names, classifications, and suspicious property values in this IFC file.
Create a CSV room-area report from this IFC file.
Create a simple IFC file with one building, one storey, and four walls.
Open the IFC viewer and show examples/sample.ifc.
Apply C:\path\to\viewpoint.bcfzip in the open IFC viewer.
Clear the IFC viewer.
If IFC MCP creates a report, BCF file, or new IFC file, it returns a local download link. If you ask to view a model, IFC MCP opens a local viewer link. If your AI client does not open that link automatically, open it in your browser.
Related MCP server: IFCX MCP
Install Node.js 18.20 or newer from the official Node.js download page. Choose the LTS version for your operating system, run the installer, then reopen the app where you want to use IFC MCP.
IFC MCP uses npx, which is included with Node.js. If your app later says
node or npx is not found, reinstall Node.js LTS and reopen the app.
ChatGPT desktop supports local MCP servers over STDIO.
Open the ChatGPT desktop app.
Open Settings.
Select Plugins, then MCPs.
Click Add. If prompted for a server type, choose STDIO.
Enter:
Name: ifc-mcp
Command to launch: npx
First argument: -y
Second argument: ifc-mcp
Leave the environment variable fields empty and save the server.
Restart the ChatGPT desktop app.
Start a new chat, type /mcp, and confirm that ifc-mcp is connected.
For more detail, see OpenAI's MCP documentation.
Option 1: Use the Claude Desktop UI
Open Claude Desktop.
Open Settings.
Open Developer or Desktop app developer settings.
Click Edit Config if that button is available. This opens the Claude
Desktop MCP config file.
Paste the JSON below, save the file, then fully quit and reopen Claude Desktop.
{
"mcpServers": {
"ifc-mcp": {
"command": "npx",
"args": ["-y", "ifc-mcp"]
}
}
}If the file already contains JSON, add only the ifc-mcp entry inside the
existing mcpServers object. Do not create a second mcpServers object.
Option 2: Open the config file directly
Use this only if you do not see Edit Config in Claude Desktop:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Paste the same JSON from Option 1, save the file, then fully quit and reopen Claude Desktop.
Check
To check the setup, open Claude Desktop, start a new chat, click the + button
near the chat box, and look for Connectors. IFC MCP should appear there after
Claude Desktop has restarted. You should see the tools listed in the
How It Works section above.
For more detail, see Claude's local MCP server guide.
Option 1: Use the install button
This opens VS Code and adds IFC MCP.
If VS Code asks whether you trust the server, accept it. Reload VS Code if the tools do not appear. Open Chat and use the tools/configure-tools button to see the IFC MCP tools.
Option 2: Add .vscode/mcp.json manually
{
"servers": {
"IFC MCP": {
"type": "stdio",
"command": "npx",
"args": ["-y", "ifc-mcp"]
}
}
}Reload VS Code after saving the file.
Open Chat and use the tools/configure-tools button to see the IFC MCP tools.
For more detail, see the VS Code MCP server docs.
Option 1: Use the Codex settings UI
Open VS Code.
Open the Codex panel.
Open Codex settings.
Select MCP servers.
Click Add server.
Enter:
Name: ifc-mcp
Command: npx
Arguments: -y ifc-mcp
Save the server.
Reload VS Code or start a new Codex session.
Check that the IFC MCP tools are available in the new Codex session.
Option 2: Use the terminal command
Open Terminal -> New Terminal in VS Code.
Paste and run:
codex mcp add ifc-mcp -- npx -y ifc-mcpReload VS Code or start a new Codex session.
Check that the IFC MCP tools are available in the new Codex session.
For more detail, see the Codex MCP docs.
Option 1: Use a project JSON file
Open your project in VS Code.
Create or edit .mcp.json in the project root.
Add this JSON and save the file:
{
"mcpServers": {
"ifc-mcp": {
"command": "npx",
"args": ["-y", "ifc-mcp"]
}
}
}Reopen Claude Code in VS Code.
Type /mcp and approve the project server if Claude asks.
Check that ifc-mcp is connected.
Option 2: Use the terminal command for all projects
claude mcp add --transport stdio ifc-mcp --scope user -- npx -y ifc-mcpThen reopen Claude Code in VS Code, type /mcp, and check that ifc-mcp is
connected.
If the claude command is not found, install Claude Code first.
For more detail, see the Claude Code VS Code docs and Claude Code MCP docs.
Add this server entry to your MCP client config:
{
"mcpServers": {
"ifc-mcp": {
"command": "npx",
"args": ["-y", "ifc-mcp"]
}
}
}Restart the MCP client after saving the config.
For more detail, see the Model Context Protocol docs.
If your app already has an IFC viewer, you can reuse IFC MCP's normal tool
interface and apply viewer actions in your app instead of opening the default
local viewer. The MCP client still calls tools like show-ifc-file and
set-bcf-view; your app only defines what those viewer tools do.
import { createServer } from "ifc-mcp";
const server = createServer({
viewer: {
"show-ifc-file": async ({ file_path }) => {
return loadIfcIntoThisViewer(file_path);
},
"set-bcf-view": async ({ bcf_path }) => {
return applyBcfToThisViewer(bcf_path);
},
"clear-ifc-viewer": async () => {
return clearThisViewer();
},
},
});The callback names and argument names match the MCP tool names and schemas, so there is no second naming system to learn.
For local development from this checkout:
npm install
npm testThe workspace includes .vscode/mcp.json, so VS Code can run the server from
this checkout.
IFC MCP keeps the IFC work on your own machine. It reads your IFC files locally, runs the IFC analysis locally, and opens a local viewer. It does not publish the viewer to the public internet.
Generated reports, BCF files, and IFC files are temporary local download links. IFC MCP does not write generated output files into your project folder by default.
Use IFC MCP only with IFC/BIM files and project folders you trust. It can read the files you ask it to use, and incorrect or misleading model data can lead to wrong reports or generated IFC files.
Clear the already-open local IFC viewer by removing all loaded IFC files and BCF viewpoint state. This keeps the same stable viewer URL and does not close the browser tab. Use show-ifc-file after this to load a fresh IFC model.
| 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 states that the operation removes all loaded files and viewpoint state, keeps the same stable viewer URL, and does not close the browser tab. These are meaningful behavioral traits that go beyond the tool's name, though it does not address reversibility or potential side effects like confirmation prompts, which are not critical for a clearing 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 extremely concise, consisting of two sentences that directly communicate the action, its scope, and the recommended next step. There is no wasted phrasing; each clause adds value. The structure front-loads the primary function and then adds relevant context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete. It clearly explains what state is cleared, what remains unchanged, and how to proceed with a fresh model. The mention of show-ifc-file provides essential workflow context, making the tool's place in the larger process clear.
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 input schema is empty, so parameter semantics are trivially satisfied. According to the rubric, 0 parameters baseline is 4, and the description does not need to add parameter details. The description appropriately focuses on the action and outcome.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Clear') and resource ('already-open local IFC viewer'), and precisely describes what it does: removing all loaded IFC files and BCF viewpoint state. It also differentiates from siblings by noting it keeps the same stable viewer URL and does not close the browser tab, which distinguishes it from open-ifc-viewer and show-ifc-file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use (already-open viewer) and explicitly directs the next step: 'Use show-ifc-file after this to load a fresh IFC model.' However, it does not explicitly mention when not to use it or compare with other siblings like open-ifc-viewer or set-bcf-view, though the primary use case is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open or show the local IFC viewer and return its stable viewer URL. This tool does not load IFC files and does not change selection/isolation state. After this tool returns, use the returned URL as the viewer address. If the client can open links, open that local URL; otherwise tell the user to open the URL in a browser or webview. Use show-ifc-file to show IFC files. Use set-bcf-view to apply a BCF viewpoint file. Do not use browser automation to click or select elements in the viewer.
| 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 full burden. It discloses non-behaviors (does not load files, does not alter selection/isolation), states the output is a stable URL, and gives post-return instructions. This is thorough behavioral disclosure for a zero-parameter 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 about 100 words but every sentence adds value: purpose, non-goal clarification, usage instructions for the returned URL, sibling references, and an explicit prohibition. It is front-loaded with the primary purpose and remains structured 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?
Given the tool's simplicity (no params, no output schema), the description fully covers its function, limitations, and integration with sibling tools. It leaves no ambiguity about what the tool does or how to proceed after invocation, making it complete for its 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?
The tool has zero parameters, and the schema is empty. The baseline for zero params is 4, and there is no need for the description to explain parameters. The description adds no parameter info, but none is required.
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 opens/shows the local IFC viewer and returns its stable viewer URL. It explicitly differentiates from siblings by noting it does not load IFC files or change selection/isolation state, and references show-ifc-file and set-bcf-view for those purposes.
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?
Explicit guidance is given: use this tool for opening the viewer, use show-ifc-file to display IFC files, use set-bcf-view to apply BCF viewpoints. It also instructs what to do with the returned URL and warns against browser automation for clicking/selecting, providing clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute LLM-created Python in the SDK Node/Pyodide IFC runtime. Use this tool for IFC inspection, validation, reports, exports, and creating new IFC files.
Runtime context: Pyodide uses the bundled Pyodide 0.28.2 runtime. The package set includes micropip, ifcopenshell, numpy, pandas, matplotlib, shapely, and typing-extensions. The Python code is passed directly to the SDK.
File inputs: pass IFC/IFCXML/IFCZIP file paths in the files array. In the desktop Node server these are local filesystem paths; in a browser host they are browser-defined paths resolved by that host. Generated Python can open those files by name, e.g. ifcopenshell.open("model.ifc") or open("model.ifc", "rb").
Return contract: this tool exposes stdout, stderr, saved_files, uploaded_files, and any result returned by the raw SDK. Generated files are returned as temporary localhost download URLs in saved_files. Do not assume files were written to the user's working directory.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Raw Python code to execute through the SDK. Files passed through files can be opened by name, e.g. ifcopenshell.open("model.ifc") or open("model.ifc", "rb"). | |
| files | No | Optional array of IFC/IFCXML/IFCZIP file paths. Desktop hosts use local filesystem paths; browser hosts use browser-defined paths. | |
| timeout_seconds | No | Timeout in seconds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the Pyodide version (0.28.2), the available package set, file path behavior differences in desktop vs browser hosts, and the return contract including stdout, stderr, saved_files, uploaded_files, and the fact that generated files are temporary URLs rather than written to the user's directory. This is highly transparent.
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 organized into four short paragraphs, each earning its place: purpose, runtime context, file inputs, and return contract. It is concise yet comprehensive, with no redundant or vague sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex code execution tool with no output schema, the description adequately covers runtime details, package availability, file path resolution in different hosts, and the exact return structure including URL handling. It provides enough context for an agent to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (code, files, timeout_seconds) are fully described in the schema, giving 100% coverage. The description adds general runtime context but does not add meaning beyond what the schema already states for each parameter. 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 uses a specific verb 'Execute' with a clear resource: 'LLM-created Python in the SDK Node/Pyodide IFC runtime.' It lists concrete use cases (IFC inspection, validation, reports, exports, creating IFC files) and differentiates from sibling viewer tools by emphasizing code execution rather than visualization.
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 states 'Use this tool for IFC inspection, validation, reports, exports, and creating new IFC files,' providing clear context for when to invoke it. It does not explicitly exclude alternatives or name viewer tools as alternatives, but the sibling names make the distinction obvious. This earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the view state in the already-open local IFC viewer by applying a BCF/BCFZIP viewpoint file. Pass either a local BCF/BCFZIP file path or a generated BCF download URL from run Python saved_files. This tool does not show/load IFC files; use show-ifc-file for that. It should not open a new browser tab and should not use browser automation. To generate a BCFZIP with run-python, write a .bcfzip file, then call set-bcf-view with saved_files[0].url:
from uuid import uuid4
import ifcopenshell
from bcf.v3 import model as mdl
from bcf.v3.bcfxml import BcfXml
from bcf.v3.visinfo import VisualizationInfoHandler
model = ifcopenshell.open("sample.ifc")
gid = model.by_type("IfcWall")[0].GlobalId
component = mdl.Component(ifc_guid=gid)
visinfo = mdl.VisualizationInfo(
guid=str(uuid4()),
components=mdl.Components(
selection=mdl.ComponentSelection(component=[component]),
visibility=mdl.ComponentVisibility(
default_visibility=False,
exceptions=mdl.ComponentVisibilityExceptions(component=[component]),
),
),
)
bcf = BcfXml.create_new(project_name="IFC MCP")
topic = bcf.add_topic("Review wall", "Review wall", "ifc-mcp", topic_type="Issue", topic_status="Open")
topic.add_visinfo_handler(VisualizationInfoHandler(visinfo))
bcf_path = "view.bcfzip"
bcf.save(bcf_path)
print(str(bcf_path))| Name | Required | Description | Default |
|---|---|---|---|
| bcf_path | Yes | Local BCF/BCFZIP file path, or a generated BCF download URL from run Python saved_files, to apply in the viewer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: it only sets view state in an already-open viewer, does not show/load IFC files, should not open a new tab, and should not use browser automation. It also implies a prerequisite (viewer must be open). However, it does not mention return values or error handling, which would contribute to full 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 core description is concise and front-loaded, with the first sentence stating purpose and the next clarifying input. The long code example earns its place by showing a complete workflow, but it adds length. Overall, it is well-structured and not wasteful, though it could be slightly tighter without losing 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 simple schema (one param, no output schema) and lack of annotations, the description provides adequate context: purpose, input types, exclusions, and a full usage example. It even gives a Python code sample for generating the BCFZIP. However, it stops short of explaining the tool's return value or potential errors, which is a minor gap for an otherwise clear description.
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% for the single parameter, so the baseline is 3. The description repeats the same information about accepting a local path or generated URL, but adds little beyond the schema description. The code example illustrates usage but does not substantially enhance parameter understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set the view state in the already-open local IFC viewer by applying a BCF/BCFZIP viewpoint file.' It uses a specific verb ('set'), identifies the resource ('view state in viewer'), and explicitly distinguishes from siblings by stating 'This tool does not show/load IFC files; use show-ifc-file for that.'
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 and when-not-to-use guidance: it says not to use for showing/loading IFC files and points to show-ifc-file as the alternative. It also explains a workflow with run-python to generate the BCFZIP and how to pass the URL, giving clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show one IFC file in the already-open local IFC viewer. Pass either a local IFC/IFCXML/IFCZIP file path or a generated IFC download URL from run Python saved_files. Use this for IFC model display only. Repeated calls add multiple IFC files to the same viewer. Returns the same stable viewer URL; after this tool returns, use that URL as the viewer address. Use open-ifc-viewer to open the viewer and set-bcf-view to apply a BCF viewpoint file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Local IFC/IFCXML/IFCZIP file path, or a generated IFC localhost download URL from run Python saved_files, to load into the viewer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the viewer must already be open, that calls can repeat and add files, and that it returns a stable viewer URL to use afterward. It does not mention potential failure modes or file size limits, but the key behavioral traits are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place: it states the action, the accepted inputs, the usage scope, the repeated-call behavior, the return value, and cross-references to sibling tools. It is front-loaded with the primary purpose and entirely free of 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?
Given the tool's moderate complexity, a single parameter, and no output schema, the description is complete. It explains the return value (stable viewer URL), how to use the result, and how it fits into the workflow with the sibling tools, leaving no necessary context 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?
The input schema already fully describes the single parameter at 100% coverage. The description adds valuable context by explicitly tying the file_path to 'run Python saved_files' generated URLs and listing the supported IFC formats, going slightly beyond the schema text.
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: 'Show one IFC file in the already-open local IFC viewer.' It clearly distinguishes itself from siblings by explicitly noting that open-ifc-viewer is for opening the viewer and set-bcf-view is for applying BCF viewpoints.
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 explicit when-to-use guidance ('Use this for IFC model display only') and names alternatives and complementary tools (open-ifc-viewer, set-bcf-view). It also clarifies that repeated calls add multiple files, which is a key usage constraint not otherwise inferable.
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.
v0.1.17clear-ifc-vieweropen-ifc-viewerrun-pythonset-bcf-viewshow-ifc-fileEach tool has a distinct purpose: opening the viewer, loading IFC files, clearing the viewer, applying BCF viewpoints, and executing Python code. There is no overlap in their core functions, and the descriptions clearly delineate the boundaries between them.
All tool names follow a consistent lowercase hyphenated verb-noun pattern (e.g., open-ifc-viewer, run-python, show-ifc-file). The verbs are distinct and the nouns are related to the domain, making the naming predictable and easy to navigate.
Five tools is well-scoped for an IFC viewer and scripting server. Each tool covers a necessary function without redundancy, and the count is within the ideal range for a focused MCP server.
The tool set covers the core viewer lifecycle (open, display, clear) plus BCF viewpoint application and a general-purpose Python execution tool for complex IFC operations. Minor gaps exist, such as no dedicated tool to remove a single loaded file or close the viewer, but these can be worked around with clear-ifc-viewer or run-python.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI Hub for AEC — 50+ 3D formats, clash detection, ACC integration via Autodesk Platform Services.
Convert Revit files to XKT, IFC, or DWG and query BIM data via natural language.
DXF and PDF/X-4 for AI agents: structured facts, PNG renders, an interactive in-chat viewer.
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/flinker-app/ifc-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server