Serpentine3D MCP Server

by chisomobanzi

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.7.0
Disambiguation5/5
Each tool has a clearly distinct purpose—scene queries, curve creation, surface creation, booleans, layers, measure, transform, selection, etc. The serp_command tool is a generic fallback but does not overlap with the high-level tools, so there is no ambiguity.
Naming Consistency3/5
All tools share the 'serp_' prefix, but the second part mixes verbs (import, export, measure, transform, select, undo), nouns (scene_info, boolean, screenshot, layers, command, viewport), and verb-noun pairs (create_curve, create_surface). This inconsistency is readable but lacks a single predictable pattern.
Tool Count5/5
With 14 tools, the server is well-scoped for a 3D modeling domain. Each tool covers a core area—creation, modification, inspection, import/export, viewport control—without redundancy, making the count appropriate.
Completeness4/5
The tool surface covers create, read (scene info), update (transform), and many operations like booleans, measure, layers, and import/export. Direct delete and fine-grained editing are missing, but the serp_command tool fills most gaps, so the completeness is strong with minor workarounds.
Average 3.9/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 346 commits in the last 12 weeks
- Last stable release on August 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It gives minor semantic hints like 'assign (move objects to layer)' and 'color as [r,g,b] 0-1', but does not explain side effects of delete/rename, what 'visible' or 'current' do, or any other behavioral consequences.
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 compact sentence with a clear action list, no filler, and the most important 'Manage layers' phrase front-loaded. Slight lack of structure, but every part contributes useful information.
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?
This is a multi-action tool with six parameters and no schema descriptions or annotations. The description fails to specify which parameters are required or relevant for each action, and does not cover invocation patterns or side effects. The output schema exists, so return values are less critical, but input handling remains incomplete.
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%, and the description does not compensate. It documents the valid action values and the color format, but leaves parameters like name, new_name, objects, and visible without explanation or mapping to specific actions, making correct invocation difficult.
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 identifies 'layers' as the target resource and enumerates concrete actions (list, create, rename, visible, current, color, assign, delete), which distinguishes it from sibling tools focused on other resources. The verb 'Manage' is broad, but the action list gives specific operational meaning.
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 phrase 'Manage layers' establishes a clear context for when to use this tool, and the action list implies the range of layer operations. However, it does not explicitly state when not to use it or mention alternatives among the sibling 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?
No annotations are provided, so the description carries the full burden of disclosing side effects. It explains how 'kind' interprets the points, but it does not state whether the curve is added to the scene, what the return value is, or any consequences. This is a notable gap for a creation 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 compact and front-loaded, stating the primary purpose in the first sentence and then enumerating the meaningful 'kind' options in the second. Every word earns its place; there is no filler or redundancy.
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 5 parameters, no annotations, and zero schema-level descriptions, this tool needs more context. The description only covers 'points' and partially 'kind', omitting the behavior of 'degree', 'closed', and 'name'. It is not enough for reliable invocation in varied scenarios.
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 adds meaning for 'points' (3D coordinates) and 'kind' (four interpretation modes), but it leaves 'closed', 'degree', and 'name' completely unexplained, making it hard for an agent to set them correctly.
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 opens with a specific verb-resource pair: 'Create a NURBS curve from 3D points.' This clearly distinguishes it from sibling tools like create_surface or transform, and it immediately states the core input format.
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 this tool is for making curves from given 3D points and defines the 'kind' options, which helps choose call behavior. However, it never explicitly tells when to prefer this over alternatives like create_surface, nor does it mention any exclusions or prerequisites.
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 bears full responsibility for behavioral disclosure, but it only states the import action and supported formats. It does not mention side effects (e.g., overwrites, new objects), permissions, or failure modes, which is a significant gap for a mutation-like 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 one concise sentence, front-loaded with the verb and resource, with no unnecessary words. Every word earns its place by listing the key file formats.
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?
Given the low complexity (one parameter) and presence of an output schema, the description provides a minimal but adequate understanding of the tool's core function. However, it lacks usage guidelines and behavioral details, which would be expected for a tool that imports external files and could have side effects.
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 schema has a single `path` parameter with 0% description coverage, so the description must compensate. The description implies that `path` is the file to import and lists supported formats, providing some meaning beyond the schema. However, it lacks details on path syntax, absolute vs. relative paths, or additional constraints.
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 (import) and the resource (a file into the scene), and lists supported file formats. This distinguishes it from siblings like serp_create_curve (creating geometry) and serp_export (exporting files).
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, nor does it mention any prerequisites or restrictions. It only states the basic function, leaving the agent without clear usage context.
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 carries the full burden of disclosing behavioral traits. It does not state whether the tool is read-only, whether it operates on existing geometry, what 'targets' means, or what happens if the required parameter is missing. The terse description leaves significant ambiguity for an agent.
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, dense sentence that front-loads the core action ('Measure geometry') and then conveys the parameter dependencies efficiently. Every part earns its place, but the compact format could be slightly improved with clearer separation of the measurement modes.
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 tool has three parameters, one required, and no annotations. The output schema exists but is not shown, so the description need not cover return values. However, it fails to explain target references, side effects, error conditions, or how the tool relates to the current scene, leaving it incomplete for nuanced usage.
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?
Schema description coverage is 0%, so the description must compensate. It adds the allowed values for 'what' and the dependency between 'what' and the other parameters, which is meaningful. However, it does not explain the coordinate format for 'points' or what 'targets' refer to (object names, IDs, etc.), leaving gaps that the schema does not fill.
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 tool measures geometry and enumerates specific measurement types (distance, length, area, volume, bbox, centroid). This verb+resource pairing is distinct and establishes a clear purpose separate from sibling tools that create, transform, or select geometry.
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 provides clear usage context by specifying which parameter is needed for each measurement type ('distance' needs points; others need targets). While it doesn't explicitly exclude alternatives or say 'use this when you need X', the mapping of parameter dependencies gives practical guidance on how to invoke it correctly.
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 behavioral transparency. It clearly indicates a read operation ('Get') and enumerates the returned data, which is adequate. However, it omits potential edge cases like empty scenes or performance implications of returning the full scene.
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 leads with the action and resource, followed by a concise enumeration of return fields. Every word adds value, with no unnecessary text.
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, read-only tool with an output schema, the description sufficiently covers what the tool does. It could benefit from a note on when to prefer it over more targeted sibling tools, but that gap is captured in the usage dimension.
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 already fully covered and the baseline is 4. The description adds no parameter details, but none are needed since there are no inputs to explain.
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 'Get' with a specific resource ('current scene') and lists the exact data returned (objects, layers, selection, bounds, display mode). This clearly distinguishes it from sibling tools like serp_layers or serp_select, which focus on individual aspects.
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 siblings such as serp_layers or serp_select. It simply states what it does, leaving the agent to infer usage context from the sibling names.
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 carries the full burden of disclosure. It indicates undo/redo are state-changing operations but does not mention potential side effects, such as whether undone operations can be recovered, whether the undo history is limited, or whether it affects only certain object types. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core functionality and the optional parameter in a compact, front-loaded manner. Every word contributes meaning, with no unnecessary elaboration.
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 one-parameter tool with an output schema, the description is largely sufficient. It covers the main behavior and parameter semantics. However, it omits caveats like the scope of 'last operation' (e.g., across all scenes or within current scene), which could be relevant in a complex 3D environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines `redo` as a boolean with a default, but the description explicitly explains its meaning: setting `redo=true` triggers redo instead of undo. This directly adds semantic value beyond the raw schema, making the parameter's effect completely clear.
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 tool's function: undoing the last operation, with an explicit mention of the redo capability via the `redo` parameter. It is distinct from sibling tools, which focus on creation, measurement, transformation, etc., so there is no ambiguity about what this tool does.
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 (i.e., after performing an operation to reverse it), but it does not explicitly state when to use it vs. alternatives, nor does it mention any prerequisites or exclusions. For a standard undo/redo tool, this is acceptable but lacks explicit guidance.
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 only lists parameter syntax and does not reveal side effects such as whether 'move' mutates the original, whether 'copy' creates new objects, or the exact semantics of 'keep_original' in mirror. 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 compact and structured as a syntax reference, with no verbose fluff. The multiline operation/params listing is efficient, though it could be slightly clearer with examples or expanded explanations for each operation.
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?
The tool has an output schema, so return values need not be described. All five operations and their parameters are documented, making the description sufficient for most selection and invocation needs. However, the lack of behavioral context (side effects, safety) prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a generic 'params' object with no internal structure. The description fully specifies the parameter layout for each operation, including defaults (e.g., axis defaults to Z) and parameter formats (offset, center, factor, plane_point). It also clarifies that targets are object names. This adds substantial meaning beyond 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 'Transform objects (by name)' and enumerates five specific operations (move, copy, rotate, scale, mirror), distinguishing it from sibling tools like boolean, create, or measure. The verb+resource is clear and specific.
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 makes the tool's scope obvious (any transformation operation) and implies when to use it. However, it does not explicitly discuss alternatives or scenarios where another tool would be preferred, so it falls short of a full 5.
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?
The description discloses that 'tools are consumed', which is a key side effect not covered by annotations (none provided). It omits whether targets are also consumed or replaced, and does not describe the output or whether the operation modifies the scene in place.
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, information-dense sentence with no redundant phrases. Every clause adds value: the operation types, the difference semantics, and the consumption warning.
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 covers the core operation and tool consumption, but lacks details on whether targets are also destroyed, how solids are referenced, and what the tool returns (though an output schema exists). These gaps leave room for misinterpretation in a destructive operation.
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?
With schema description coverage of 0%, the description compensates by explaining the valid values for 'operation' and the roles of 'targets' vs 'tools' (especially in the difference operation). This adds meaningful context over the bare 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 tool performs boolean operations on solids, listing the three specific operations. This distinguishes it from sibling tools like serp_transform or serp_create_surface, which handle different geometric modifications.
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 context for when this tool is appropriate (combining or subtracting solids) via the operation list and clarifies the difference operation semantics ('targets minus tools'). However, it does not explicitly mention alternatives or exclusion cases.
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?
No annotations are provided, so the description carries full responsibility. It reveals key behavioral traits: inputs are supplied in order, selection prompts accept object names, 'all', or '' to finish, and it uses examples to illustrate interaction. This adds significant value beyond the bare schema.
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 front-loaded with the main purpose, followed by compact examples and a clarifying note on selection prompts. Every section serves a purpose, and while not the shortest, it is well-structured and appropriately detailed.
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?
Given the tool's generic nature and the presence of an output schema, the description provides necessary invocation details. It covers input formatting and selection behavior comprehensively. It could mention error handling or command-specific outputs, but the output schema likely covers return values.
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?
Despite 0% schema description coverage, the description compensates by explaining 'command' as the command line string and 'inputs' as the ordered array of interactive inputs. Examples (circle, extrude, zoomextents) provide concrete usage semantics, making parameter meaning clear.
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 tool runs any Serpentine3D command with interactive inputs, using specific verbs and a clear resource. It distinguishes itself from sibling-specific tools by being the generic catch-all command runner.
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 arbitrary commands not covered by dedicated sibling tools, but it does not explicitly mention when to prefer this tool over alternatives or any exclusions. The guidance is inferred from the 'any command' phrasing.
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, the description carries the full burden of behavioral disclosure. It clearly states the action (capture the current 3D viewport) and the return type (PNG image). Since this is a non-destructive capture, no warnings about side effects are necessary, but it could mention that it uses the active camera/viewpoint.
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 consists of two short sentences. The first sentence conveys the core function and purpose, and the second adds a usage hint. Every word earns its place; no redundancy or filler.
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 screenshot tool with one optional parameter and no output schema, the description is largely complete: it states what is captured, the return format, and when to use it. The only gap is that it does not explicitly mention the width parameter or clarify that it captures the current viewport state (camera, layers, etc.), but overall it provides enough context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (width) with 0% description coverage, and the description never mentions width or its meaning. The parameter name is somewhat self-explanatory, but the description does not compensate for the low schema coverage or clarify how width affects the output (e.g., pixels, aspect ratio).
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 ('capture') and resource ('current 3D viewport'), clearly distinguishing it from sibling tools like serp_scene_info or serp_viewport. It also states the purpose ('so you can see the model'), making it immediately obvious what the tool does.
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 explicitly recommends using this tool after making changes to check the result, giving a clear use case. However, it does not mention when not to use it or name alternatives (e.g., serp_viewport for viewport control), so it lacks explicit exclusions.
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 explains the zoom_extents effect and lists parameter options, but does not disclose whether the viewport change impacts the active view persistently or requires an open scene. This is adequate for a simple view control but lacks deeper behavioral context.
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 compact and information-dense, with each parameter listed along with its valid options in a single sentence. There is zero filler—every word contributes to understanding the tool.
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?
Given the tool's simplicity, the presence of an output schema, and full parameter documentation, the description is largely complete. It lacks mention of prerequisites (e.g., active viewport) and side effects, but for a viewport adjustment tool this is likely sufficient. A slightly more complete description would note that changes affect the current view only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description fully compensates by documenting each parameter: view lists all valid orientations, display_mode lists valid visual styles, and zoom_extents explains its behavior. This is comprehensive for a 3-parameter tool and adds significant meaning beyond 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 explicitly states the tool's function ('Adjust the viewport') and enumerates all view orientations and display modes, making its purpose unambiguous. It clearly distinguishes itself from sibling tools by focusing solely on viewport manipulation.
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 (adjusting the viewport) but provides no explicit when-to-use or alternative guidance. It does not mention when to prefer this over other scene tools, though the intent is clear from the name and 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, the description must carry the behavioral disclosure. It does reveal operation-specific behavior, such as 'closed profiles become solids' for extrude with cap, and defaults for distance and angle. However, it does not disclose whether the operation modifies source curves, what happens on failure, or what the output object is (e.g., its name or type). This is a moderate level of transparency.
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 compact and well-structured. It leads with a one-sentence purpose, then a bullet-style list of operations and their parameters. Every line adds value with no redundancy or padding.
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?
Given the tool's complexity (five operations, variable params) and the existence of an output schema (which can convey return value details), the description covers the core usage well: it specifies prerequisites (existing curves), operation parameters, and defaults. It falls short only on the unexplained `name` parameter and edge-case behaviors, but overall it is sufficiently complete for typical use.
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?
Schema description coverage is 0%, so the description compensates by detailing `operation` values and the structure of `params` for each operation, including defaults and example vector format (e.g., direction [x,y,z]). It also explains how `curves` should be provided (order, count). The only gap is the `name` parameter, which is likely the output name but is not explained.
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 tool's function: 'Create a surface/solid from existing curves'. It specifies the resource (curves) and the result (surface/solid), and enumerates the supported operations (extrude, revolve, loft, planar, sweep), which distinguishes it from sibling tools like serp_create_curve (which creates curves) and serp_boolean (which operates on existing solids).
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 gives a clear context for use: creating surfaces/solids from existing curves. It does not explicitly compare with alternatives or state when not to use it, but the purpose is so specific that an agent can readily infer appropriate usage scenarios. No exclusions are mentioned, but none are needed for such a specialized tool.
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?
No annotations are provided, so the description carries the full burden. It clearly discloses the file-writing behavior and format selection, but it does not mention whether existing files are overwritten, whether directories must exist, or any error conditions. For a straightforward export tool, this is moderate transparency.
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 sentence that front-loads the action ('Export') and includes the essential qualifiers: target (scene/selection), formats, and format selection mechanism. Every word earns its place; no 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?
The tool is conceptually simple, and the description covers the core behavior and parameters. An output schema exists, so return-value documentation is not needed. The main missing context is file-overwrite behavior and potential failure modes, but overall the description is sufficiently complete for this export 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'path' parameter by explaining that the extension determines the format, and it clarifies that 'selected_only' controls whether the scene or current selection is exported. This is valuable context beyond the raw 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 tool exports a scene or selection to specific 3D file formats (.serp, .step/.stp, .obj), with the format determined by the file extension. This is a specific verb+resource+behavior that distinguishes it from siblings like serp_import and serp_screenshot.
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 provides clear context: you can export either the whole scene or the current selection, and the format is chosen by the file extension. It does not explicitly mention when to use this over alternatives, but among the siblings only serp_screenshot is a visual export, and this tool's purpose is distinct enough that no exclusion is necessary.
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 successfully communicates selection-mode semantics and the special behavior of 'clear'. It could go further by explaining whether criteria combine with AND/OR, but the core behavioral traits are adequately disclosed.
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 compact and front-loaded: the first sentence states the primary action and criteria, and the second sentence provides essential mode information. Every phrase adds value without 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?
The tool has four optional parameters, no annotations, and an output schema is present, so return values need not be explained. The description covers all parameters and key behaviors, though it leaves some edge cases (e.g., whether multiple criteria are combined) undocumented. Overall, it is sufficiently complete for a selection 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?
Schema property descriptions are absent (0% coverage), so the description must add meaning. It compensates well by explaining the meaning of 'kind' with the allowed values (curve/surface/solid) and clarifying mode behavior. It does not define the exact expected format for 'names' or the default behavior when 'mode' is omitted, but the overall parameter semantics are much clearer thanks to the description.
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') and the criteria (names, kind, layer), which makes the tool's purpose immediately understandable. It is distinct from sibling tools like serp_create_curve or serp_boolean, focusing specifically on selection.
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 explains the mode parameter ('replace', 'add', 'clear') and highlights the non-obvious behavior that 'clear ignores other args', which is directly useful for invoking the tool. It does not explicitly name alternative tools or exclusions, but no sibling tool is a selection tool, so the intended usage context is clear.
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:

[![Serpentine3D MCP server](https://glama.ai/mcp/servers/chisomobanzi/Serpentine3D/badges/card.svg)](https://glama.ai/mcp/servers/chisomobanzi/Serpentine3D)

Score Badge

Copy to your README.md:

[![Serpentine3D MCP server](https://glama.ai/mcp/servers/chisomobanzi/Serpentine3D/badges/score.svg)](https://glama.ai/mcp/servers/chisomobanzi/Serpentine3D)

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/chisomobanzi/Serpentine3D'

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