Outline
In the previous article, we introduced the technical roadmap and implementation cases of MCP, and this article will discuss in depth how to improve the case under the multi-round thinking chain. Taking the wall as an example, this time I don't want the user to participate in the interaction, and try to let the computer automatically complete the calculation. The requirement has been changed from "Create a Wall - > user Select a Wall - > Insert a Random Location Door or Window" to "LLM automatically calculates the wall ordinate and inserts a different form on each wall. The following content will focus on the modification of prompt words and code adjustments under the multi-round thinking chain.
The case unfolds
address
Github：[https://github.com/imkcrevit/RevitMCP_Blog/tree/main](https://github.com/imkcrevit/RevitMCP_Blog/tre...)
prompt
The code of this project has not changed much, and the main way of description is optimized, so that the LLM can understand and accurately call the Tool to run the program. The following describes the logical adjustments when modifying a simple case to a multiple chain of thought format.
steps
- First, test in MCP.Client, enter a paragraph, and see if the LLM can parse multiple tools:
Create a group of walls, the wall anchor line is required to be a closed figure and not less than three, the minimum length is 10000mm, the wall height is 3000 by default, after the creation of the wall, the wall is inserted at a random position, the window ordinates of each wall are inconsistent, and the requirements cannot exceed the height of the wall.
You can see that the output is two Tools, which proves that the description can be parsed correctly by the LLM and assigned to different Tools.
- Continuing with testing, the above prompt does not clarify the definition of "a set of walls", resulting in the LLM being recognized as a wall, which is not as expected. After changing the prompt word, no less than three constraints are added, as shown in the screenshot below:
Create a group of walls, the wall anchor line is required to be a closed graphic and not less than three, the minimum length is 10000mm, the wall height is 3000 by default, after the wall is created, the window ordinate of each wall is inconsistent, and the height of the wall cannot be exceeded.
LLM has created three sets of walls, proving that the previous "one set equals one wall" was the result of an inaccurate description.
The LLM generates three sets of walls, and the tools become a list of three items.
At this time, we are faced with the problem of how to accurately insert doors and windows into the specified wall, and because it is impossible to obtain the wall ID created in time, it can only be replaced by numbers.
- Since IDs can't be passed, it's a whole chain of thought that doesn't involve waiting for creation to be completed or user selection. The options are as follows:
- Add the uniqueId based on the GUID format as the unique logotype, and pass in the form combination as the host basis (this project uses this scheme)
- After each creation is completed, the widget ID is returned and replaced with the next chain of thought binding tool as the data source.
Modify the prompt to emphasize the generation of a unique logotype and pass in:
Create a group of walls, the wall anchor line is required to be a closed graphic and no less than three, and there is a unique logotype, guid format, take it as the ID, the minimum length is 10000mm, the wall height is 3000 by default, after the wall is created, the window ordinates of each wall are inconsistent, the requirements can not exceed the height of the wall, accurately understand my intention, and split it and call the function in the corresponding order
At this time, the eID in the generated data has not changed, indicating that the LLM does not understand the intent. You need to change the description of the tool in the server and adjust the system settings to let it know that the unique logotype is in GUID format.
On the server, modify the Create description so that the LLM explicitly passes in the UniqueId when traversing the Tool:
[McpServerTool(Name = "CreateWall"),
Description("Generation Paramaters That Can Create Wall in Revit ,
If User Want To Generation eId ,
You Need To Generation a unique id base this :0B7FB9A8-DAD8-48CE-9D41-5EDB63832BD2 ")]
The system side also emphasizes the definition of unique logotypes:
"""you are a professional enginer in BIM ,
so you can select the greate tool to user ,
also has a good develop tech in code ,
and generation a standard input style And Arguments to tools ,
also if some question need unique id you will generate a unique eId in this talk ,
the example :0B7FB9A8-DAD8-48CE-9D41-5EDB63832BD2"""
The final output result is still eId = 2, because the method input parameter format is int, and LLM will output uniqueId to int format based on parameters, and the method parameter type needs to be modified:
public string RevitCreateWallTool(string command, double x, double y, double z, double x1, double y2, string uniqueId) {
return $@" {{
""command"": ""CreateWall"",
""arguments"": {{ ""start"": [{x}, {y}, {z}],
""end"": [{x1}, {y2}, {z}], ""eId"": ""{uniqueId}"" }} }}";
}
- Re-test the input statement and find that the ID has been assigned accurately, but the wall generated by the LLM is not closed, resulting in abnormal data. LLMs are not mature in terms of two-dimensional representation and cannot simulate two-dimensional or 3D graphics like humans. A detailed description can be added to the input.
- Add the closure definition constraint (end-to-end intersection), and the result meets the requirements.
- Add the correspondence between the form and the wall, which is described as mathematical language and the ordinate projection point on the wall line segment to ensure the accuracy of the calculation.
- The optimized prompt words are as follows:
A wall corresponds to a window, and has a unique logotype logotype format is: eId = 0B7FB9A8-DAD8-48CE-9D41-5EDB63832BD2, in strict accordance with this format to generate data and can not be repeated, create a group of walls, the wall anchor line is required to be a closed graphic, the ordinate lines are connected with each other in a straight line, the first one is consistent with the last one and not less than three, the minimum length is 10000mm, and the wall height is 3000 by default, After creating the wall, insert the window at a random position of the wall, the anchor point of the window must be on the generated wall anchor line, the calculation formula is: the projection point of the form must be on the line segment connected by the end of the wall, each wall corresponds to a window, which needs to be calculated separately, the window ordinates of each wall are inconsistent, and the requirements cannot exceed the height of the wall, accurately understand my intention, and calculate in strict accordance with the requirements, and split the function in turn according to the corresponding order
Sample output:
[
{
"command": "CreateWall",
"arguments": {
"start": [0, 0, 0],
"end": [10000, 0, 0],
"eId": "0B7FB9A8-DAD8-48CE-9D41-5EDB63832BD2"
}
},
{
"command": "CreateWall",
"arguments": {
"start": [10000, 0, 0],
"end": [10000, 10000, 0],
"eId": "1A2B3C4D-5E6F-7G8H-9I10-11K12L13M14N"
}
},
{
"command": "CreateWall",
"arguments": {
"start": [10000, 10000, 0],
"end": [0, 10000, 0],
"eId": "15O16P17Q-18R19S-20T21U-22V23W-24X25Y26Z"
}
},
{
"command": "CreateWall",
"arguments": {
"start": [0, 10000, 0],
"end": [0, 0, 0],
"eId": "27A28B29C-30D31E-32F33G-34H35I-36J37K38L"
}
},
{
"command": "InsertWindowInWall",
"arguments": {
"eId" : "0B7FB9A8-DAD8-48CE-9D41-5EDB63832BD2",
"location": [5000,0,1500]
}
},
{
"command": "InsertWindowInWall",
"arguments": {
"eId" : "1A2B3C4D-5E6F-7G8H-9I10-11K12L13M14N",
"location": [10000,5000,1500]
}
},
{
"command": "InsertWindowInWall",
"arguments": {
"eId" : "15O16P17Q-18R19S-20T21U-22V23W-24X25Y26Z",
"location": [5000,10000,1500]
}
},
{
"command": "InsertWindowInWall",
"arguments": {
"eId" : "27A28B29C-30D31E-32F33G-34H35I-36J37K38L",
"location": [0,5000,1500]
}
}
]
effect
> note that the video in the original post must be replaced
summary
When the number of walls is increased to five, there is an error, and only the end-to-end joint definition is used, and the LLM is still insufficient in 2D data processing. LLM is limited in such scenarios that need to be created continuously in Revit, especially when it comes to 2D/3D spatial relationships. You can improve the accuracy by optimizing the prompt words, and the LLM may be able to perform better in the future. The case shows that logical review can be used to achieve more applications through MCP, such as judging multiple code conditions and creating logotypes. The code has been synchronized to Github, welcome to download the extension, the article mainly proves the technical feasibility, and the specific application needs to be combined with the actual work.
This article was written and published under Chinese and is a translation of the original here.
只有注册用户才能在此添加评论。 如果您已经注册，请登录。 如果您还没有注册，请注册并登录。