MaxForge MCP

by BluntMan-420

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct operation in the 3ds Max domain: scene state, materials, animation, scripting, selection, object creation, transformation, properties, deletion, export, and saving. Even the two scripting tools (run_maxscript and run_python) are cleanly separated by language, and set_property vs. transform have clear boundaries (arbitrary vs. spatial transformation). No two tools appear to do the same thing.
Naming Consistency3/5
The majority of tools follow a verb_noun pattern (apply_material, set_keyframe, get_scene_info, create_object, set_property, save_scene, add_modifier). However, several tools use bare verbs (select, transform, delete, export, ping) and two use verb_language (run_maxscript, run_python). This mix of patterns is readable but not fully consistent.
Tool Count4/5
With 17 tools, this is slightly above the ideal 3-15 range but still appropriate for a comprehensive 3ds Max bridge that covers modeling, animation, scene management, and export. The tools are not redundant, and the count reflects the breadth of operations required for a professional DCC integration.
Completeness4/5
The surface covers the core lifecycle: create, inspect, modify, delete, select, save, export, and add modifiers. It also handles materials and keyframes. Minor gaps include lack of a dedicated get_property tool (though run_maxscript can access anything) and no duplicate or group operations. Overall, agents can accomplish most workflows without dead ends.
Average 3.3/5 across 17 of 17 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('set') which implies mutation, but does not explain what happens if a keyframe already exists, what 'frame number' refers to, or any side effects. The description is too minimal to give the agent confidence about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundancy, which is structurally sound and front-loaded. However, it is under-specified for the tool's complexity—conciseness should not come at the cost of missing essential information. It is acceptable but not exemplar.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, no output schema, and 0% schema description coverage, the description is entirely inadequate. It does not explain the meaning of the parameters, the coordinate system, keyframe interpolation behavior, or any return value. An agent cannot use this tool correctly with only this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but does not. It only hints at 'frame number' (likely the 'time' parameter) and 'object' (likely 'handle') but provides no explanation for pos, rot, or scale. The agent cannot determine what these arrays represent or how they relate to keyframe interpolation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('set') and resource ('animation keyframe on an object') and mentions the frame number as the time context. It is specific enough to distinguish from generic mutation tools like set_property or transform, though it does not explicitly name a sibling alternative. A 4 is appropriate because it is clear but does not differentiate among the animation-specific siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like transform or set_property. It does not state prerequisites, such as whether the object must already exist or whether the keyframe replaces existing ones. With no exclusions or alternatives, the agent is left to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone carries the burden of behavioral disclosure. It states 'delete' which implies destruction, but does not explicitly mention that the operation is irreversible, what side effects occur (e.g., broken references, removal from scene), whether permissions are required, or what happens to dependent objects. The description fails to add context beyond the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no fluff. It is extremely concise and front-loads the core action. However, it is so terse that it borders on under-specification rather than efficient brevity, but it still earns credit for having no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema and incomplete parameter documentation, the description is markedly incomplete. It does not mention the permanence of deletion, any confirmation or undo options, how to retrieve handles (e.g., from list_objects), or what the expected result is. The agent has almost no guidance beyond the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage; the only hint about the parameter is the word 'handles' in the description, but it does not explain what a handle is, how to obtain it, or its format beyond the schema's array of integers. The description does not add meaningful semantic value beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete objects by handle' clearly states the verb 'delete' and the resource 'objects', and specifies the distinguishing method (by handle). It is specific enough to act, though it does not elaborate on what 'objects' refers to in context or contrast with specific siblings beyond the fact that no other tool is named 'delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no mention of selection vs. handles, and no conditions for when not to use it. For a destructive operation, this is a significant gap; the agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions that the tool writes to disk and that the exporter depends on the file extension, but it does not disclose side effects such as file overwriting, error handling, required permissions, or what happens if the path is invalid. It also does not describe the return value or success/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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and the key behavior (exporter selection by extension). It avoids unnecessary words, but it sacrifices detail for brevity, omitting information about parameters and behavior that would improve utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It does not explain the format parameter, the meaning of handles, or what happens when handles is null. It also lacks information about file paths, potential errors, or expected results. An agent would likely need additional external knowledge to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It implicitly references the handles parameter ('or just the given handles') and the path parameter (via extension), but it does not explain the format parameter at all, nor does it clarify the semantics of handles (e.g., what handles are expected or that null means whole scene). An agent would be unsure about the format argument and whether it overrides the extension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Export the scene (or just the given handles) to disk.' It specifies the resource (scene/handles) and the destination (disk), and it hints at the mechanism (exporter chosen by file extension). However, it does not explicitly differentiate from sibling tools like save_scene, which also writes to disk, leaving some ambiguity about when export is the right choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention any sibling tool or condition that would prefer another operation. It only implies usage by stating the exporter is chosen via file extension, but it does not explain scenarios where export is appropriate versus save_scene or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses that the operation mutates a property and returns the new value, but omits side effects, error handling (e.g., invalid property names), permissions, or reversibility. For a mutation tool, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with verb and resource, concise and without fluff. It earns its place by conveying the essential purpose and return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, no annotations, and no output schema, this description is severely incomplete. An agent cannot reliably construct a valid call without understanding the handle and value format, or knowing what happens on failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It only implies 'prop' is the name, but gives no guidance on 'handle' (identifier for the object) or 'value' (string representation, but MAXScript properties may expect specific types). This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'an arbitrary MAXScript property on an object', and the return behavior ('return its new value'). This distinguishes it from siblings like run_maxscript and apply_material, which are about execution and material assignment respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as run_maxscript or add_modifier. The description does not mention typical scenarios, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses that the filter is case-insensitive and provides the output schema, which is helpful. However, it does not explicitly state that listing is a read-only operation with no side effects, nor mention any performance implications (e.g., potentially large result sets). The verb 'list' implies read-only, but the description 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. The output format is front-loaded, and the filter behavior is given concisely. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple listing tool but incomplete: it fails to explain the `selected_only` parameter, which is a core part of the tool's options. It also does not clarify scope (e.g., whether all objects or only top-level ones are listed) or any limits. While the output format is specified, the missing parameter explanation and scope ambiguity leave an agent with questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the `filter` parameter (case-insensitive match against name or class), adding meaning beyond the bare schema. However, the `selected_only` parameter is completely undocumented; its default is `false` but what it does is not explained. With 0% schema coverage, the description should compensate for both parameters but only covers one, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists scene objects and specifies the output fields ({handle, name, class, pos, bbox}). The verb 'list' and resource 'scene objects' are specific. However, it does not explicitly differentiate from siblings like get_selection or get_scene_info, relying on the name and context to imply the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description does not mention that get_selection exists for selected objects or any exclusions. An agent must infer usage solely from the name and description, which is insufficient for deciding between similar listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it 'sets' values, implying an overwrite, but does not specify what happens to unspecified parameters (likely unchanged, but not stated), whether the operation is reversible, requires a valid handle, or what error conditions exist. Crucial behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the verb and resource. It uses clear, unambiguous terminology with no superfluous content. Minor structural improvement could be made by explicitly noting that each parameter is optional, but overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema coverage, the description is far from complete. It lacks guidance on parameter formats (array length), handle semantics, behavior when parameters are omitted, and error conditions. Given the tool's mutating nature, an agent needs more context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to pos, rot, and scale by explaining they are position, Euler rotation (degrees XYZ), and scale. However, it does not specify that arrays must have length 3, nor does it explain the handle parameter. Schema description coverage is 0%, so the description partially compensates but leaves significant gaps in array dimensions and handle semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'object', and enumerates specific attributes: world position, Euler rotation (degrees, XYZ), and scale. It is explicitly transform-specific and distinguishes itself from generic siblings like set_property by naming exact transformations. The 'and/or' phrasing clarifies partial updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Siblings include set_property, which could be used to modify similar attributes, but the description does not mention any exclusions or preferences. The agent is left to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the material type ('Standard'), the optional disk-read side effect of loading a bitmap, and the assignment action. However, it does not state that assigning replaces any existing material on the objects, whether new material instances are created per call, or what happens on invalid handles — meaningful gaps for a mutating tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clean sentence that front-loads the core verb and resource, with the optional-texture detail tucked into a parenthetical that earns its place. No filler or redundancy; slightly dense but efficient and well ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters at 0% schema coverage, no annotations, and no output schema, the description is too thin. It omits material_name semantics, overwrite behavior, handle validity requirements, and error/result expectations. An agent calling this for a real scene-assignment task would need to infer too much about side effects and parameter meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It loosely maps 'diffuse bitmap texture loaded from disk' to diffuse_bitmap and 'given objects' to handles, but material_name is entirely unexplained — its default 'MCP_Material' and semantics (unique vs. reused named material) are undocumented in both schema and description. The coverage is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource ('Create a Standard material... and assign it to the given objects') and qualifies the variant ('optionally with a diffuse bitmap texture loaded from disk'). It is distinct from siblings like create_object (geometry) and set_property (generic properties); an agent can tell this is material-specific without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives such as set_property or run_maxscript, nor any exclusions (e.g., only for Standard materials, or not for physically-based materials). Usage context is only implied by the name and field names, leaving the agent to infer the right invocation scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full weight of behavioral disclosure. It only says 'Save the current scene,' implying a write operation but not detailing overwrite behavior, return values, or failure modes. It does not mention whether saving to a new path creates a file or how existing files are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, with the core purpose front-loaded and the parameter guidance following. Every word earns its place, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple save operation with one optional parameter, the description covers the essential action and parameter semantics. But it omits differentiation from the export sibling, potential side effects like overwriting, and any expected return value. Given no annotations, this leaves gaps that an agent might need to infer or test.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the only parameter beyond the schema's bare 'Path' field: 'Omit path to save in place' indicates that providing a path saves to that location and omitting it saves in place. This adds meaningful semantic context that the schema lacks, compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Save the current scene.' This distinguishes it from most siblings like apply_material or create_object. However, the presence of an 'export' sibling introduces potential ambiguity, as 'save' and 'export' can overlap, but the description does not address this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'Omit path to save in place,' which instructs on parameter use but offers no context on when to prefer this tool over alternatives like export. It does not specify prerequisites, scenarios, or conditions for selection, leaving the agent to infer when saving is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects (e.g., modifies the scene permanently), prerequisites (object must exist or be selected), or failure modes. It only states the core action, leaving behavioral traits under-specified 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and includes illustrative examples. No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a required undocumented parameter, the description is insufficient for a complete understanding. It omits how the object is referenced, any return value, and important behavioral details, making it inadequate for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It clarifies that 'modifier' takes a MAXScript class name and that 'params' are optional properties, but it never explains the 'handle' parameter, which is required. This leaves a required parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('add') and names the resource ('modifier') and the input type ('MAXScript class name'), with concrete examples (Edit_Poly, Bend, etc.). It clearly distinguishes this from siblings like create_object or set_property, which operate on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to add a modifier to an object) but gives no explicit guidance on alternatives or conditions like object existence or selection. It does not mention when not to use this tool or mention any competing sibling, leaving the routing decision largely to the model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions creation-time properties but does not cover side effects (e.g., object added to scene, selection behavior), error handling for invalid class names, or permission requirements. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. It avoids redundancy and is easily parseable. Minor improvement could be a more explicit separation of the type and params explanation, but it is suitably efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a creation tool with no output schema and no annotations, the description lacks essential context: return value, error behavior, and scene impact. Critical details that an agent needs to call correctly and handle outcomes are missing, so it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate. It explains `type` (class name) and `params` (with an example), but `pos` and `name` are left unexplained. Partial coverage: two of four parameters are clarified, so it only partly compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create), the resource (primitive/object), and the specific mechanism (MAXScript class name) with examples like Box, Sphere, etc. This distinguishes it from siblings like list_objects or apply_material, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (creating objects) but does not explicitly mention when to use this tool versus alternatives such as add_modifier or set_property. There are no explicit 'when not to use' conditions or comparisons to sibling tools, so the agent has to infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a critical side effect (replaces current selection), which is useful. However, it does not mention error handling, whether the operation is reversible, or what happens with invalid handles. The disclosure is partial but meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and the critical replacement behavior. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection tool, the description covers the core action but lacks details on the return value (if any) and edge cases like empty handles or invalid identifiers. Given the absence of an output schema and annotations, a bit more context would be expected, though the essential operation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameter semantics. It does not go beyond schema: 'handles' is merely an array of integers, and the description implies they identify objects but does not define what a handle is or how to obtain one. Minimal added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Select objects by handle' with a specific verb and resource, and adds a key distinction by noting it 'replaces the current selection.' This differentiates it from sibling tools like get_selection or list_objects, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as get_selection or transform. It only describes the action without mentioning context, prerequisites, or exclusions. An agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the tool checks the connection and reports scene state, implying a read-only diagnostic, but it does not explicitly confirm that it has no side effects, nor does it describe error handling or the nature of the report. Adequate but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the action and purpose with no unnecessary details. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter diagnostic tool with no output schema, the description is sufficient for an agent to know what the tool does. It misses details about failure modes or return format, but these are beyond the core purpose for a simple ping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema is trivially complete. No parameter information is needed, and the description adds nothing beyond that. The baseline of 4 for parameterless tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and resource ('bridge connection'), and also mentions reporting the scene state. It is distinct from the sibling get_scene_info because of its focus on the bridge connection, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention context, prerequisites, or when a user might prefer ping over get_scene_info or other diagnostics. The agent is left to infer that it is a health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that it creates box proxies, sizes them to world bounding boxes, and names them, but does not mention side effects (e.g., whether it modifies existing objects, creates new objects, or is destructive to same-named proxies). It adds some value but lacks detail on the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The action and naming convention are front-loaded, and the caveat about being generic is concise. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is nearly complete. It covers the creation logic, naming, and generic nature. Missing details like return values or error conditions are minor given the simplicity, and the tool's purpose is clear enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. It explains prefix's role in naming ('{prefix}{name}') but does not explicitly define 'handles' (only implies they refer to objects through 'for each given object'). No default behavior, acceptable values, or constraints for handles are mentioned, leaving the parameter meaning incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create), the resource (a simple axis-aligned box collision proxy), and the scope (for each given object, sized to world bounding box, named with prefix). It distinguishes from siblings like create_object by specifying the collision proxy purpose and naming convention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that it is a 'generic starting point, not tuned to any specific game engine's collision format yet', implying use for initial proxy creation. However, it does not explicitly state when to use or avoid this tool compared to alternatives, nor does it name any alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states the action without disclosing behavioral details such as the return format (e.g., array of object names, handles), side effects (none expected), or any system-specific behavior. The description does not contradict annotations (there are none), but it fails to go beyond the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence that front-loads the action and resource without any redundant words. Ideal conciseness for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns. It only says 'objects,' leaving the return format unspecified (e.g., names, IDs, full objects). This is a notable gap for an agent trying to interpret the result. Otherwise, the description is adequate for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers everything. The description adds no parameter info, but none is needed. Baseline 4 is appropriate given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'objects currently selected in the 3ds Max viewport,' which distinguishes it from sibling tools like 'select' that would set the selection. The purpose is immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage: it fetches the current selection. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'select' for changing selection), nor does it mention any exclusions or prerequisites. For such a simple tool, the implied usage is acceptable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly states that arbitrary Python can be executed, explains the return behavior (expression value, or `result` for statement blocks), and mentions stdout capture. However, it does not explicitly warn about potential side effects or error handling, which is a minor gap for an arbitrary execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, with the core purpose front-loaded ('Execute arbitrary Python'). Every sentence provides useful information: the interpreter context, return mechanism, and stdout handling. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 is quite complete: it covers the execution environment, return value conventions, and stdout. It lacks explicit error-handling details or caveats about side effects, but given the simplicity of the tool, these are not critical omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains that `code` is the Python code to execute, and adds crucial details about expression vs. statement block semantics and how to return values. This goes beyond the schema's bare 'Code' label, providing meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Execute') and resource ('arbitrary Python inside 3ds Max's embedded interpreter'), making the tool's purpose clear. It mentions pymxs, which ties it to Python specifically, but it does not explicitly distinguish it from run_maxscript, though the name and content imply the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Python code execution but does not explicitly state when to choose this over the sibling run_maxscript or any other alternative. It gives practical guidance on how to structure code (expression vs. statement block) but not when to use the tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that execution is arbitrary and returns a result, but does not warn about potential side effects, destructive operations, or security implications—critical for a code execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no filler, with the primary action and return behavior front-loaded. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter escape hatch, it adequately explains what it does and what it returns. Lacks explicit examples or error handling details, but these are not critical for such a generic tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'code', and the description clarifies that it is MaxScript to execute. Despite 0% schema coverage, the description adds meaning beyond the raw string type by connecting it to MaxScript and the execution behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool executes arbitrary MaxScript and returns the last expression's result, differentiating it as an escape hatch for cases not handled by typed sibling tools. This clearly establishes its purpose relative to the other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by indicating the tool is for anything not covered by typed tools, which implies a use-case boundary. However, it does not explicitly state when not to use it or name specific alternatives, only alluding to 'typed tools below'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry all behavioral disclosure. It indicates what data is returned, implying a read-only operation, but does not explicitly state that it has no side effects or specify the exact return format. It is adequate but could be more explicit about its read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that front-loads the main purpose and lists exactly what is retrieved. There is no extraneous text, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less query tool, the description fully communicates the returned values (units, frame rate, frame range, object count). There is no output schema, but the description lists the return items explicitly, so an agent knows what to expect. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. The baseline for 0 parameters is 4, and the description does not need to add parameter-level detail since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('scene info') with enumerated data points (units, frame rate, frame range, object count). This precisely distinguishes it from siblings like 'list_objects' or 'get_selection', which target different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving scene-level metadata, and the tool's name and parameter-less nature make its purpose self-evident. However, it does not explicitly state when to use it versus alternatives or mention any exclusions, though for such a simple tool this is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MaxForge-MCP MCP server](https://glama.ai/mcp/servers/BluntMan-420/MaxForge-MCP/badges/card.svg)](https://glama.ai/mcp/servers/BluntMan-420/MaxForge-MCP)

Score Badge

Copy to your README.md:

[![MaxForge-MCP MCP server](https://glama.ai/mcp/servers/BluntMan-420/MaxForge-MCP/badges/score.svg)](https://glama.ai/mcp/servers/BluntMan-420/MaxForge-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BluntMan-420/MaxForge-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server