threejs-editor-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but inspect_project and check_project both report diagnostics, and create_project also opens the editor, creating slight overlap. Descriptions generally help agents choose correctly.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., open_editor, list_projects, apply_scene_changes), making the API predictable and easy to navigate.
Tool Count5/5
With 12 tools, the server is well-scoped for a Three.js project editor, covering project lifecycle, scene manipulation, and diagnostics without unnecessary bloat.
Completeness4/5
Core workflows such as create, open, inspect, modify, save, and export are covered, but missing operations like delete_project or asset retrieval leave minor gaps in full lifecycle management.
Average 3.1/5 across 12 of 12 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
With no annotations, the description must disclose side effects and behavior. It mentions a staleness condition but does not state whether the tool modifies the project (e.g., overwrites local changes), what happens if the revision is not stale, or any permissions or error behaviors. For a 'pull' operation, this is a significant transparency gap.
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, front-loaded sentence with no redundant phrasing. It is concise and easy to parse, though the content is sparse. It earns its place but could be more informative.
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 likely syncs or pulls project state, the description is incomplete. It does not explain the full flow: what happens when the revision is current, whether the returned project is the latest version, or any error conditions. The output schema covers return structure, but not the tool's overall behavior.
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 parameter meaning. It hints at 'revision' but does not explicitly describe projectId or currentRevision beyond the schema's format patterns. It does not clarify how the parameters relate to the stale-check logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns a project, but only under the condition that the editor revision is stale. This gives some purpose but is vague about what 'pull' means (fetch, update, sync) and does not distinguish from sibling tools like inspect_project or open_editor.
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. The condition 'when the editor revision is stale' is a behavioral trigger, not explicit usage advice or exclusion of 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 provided, the description carries the full burden of behavioral disclosure. It implies a read-only check but does not state that explicitly, nor does it mention potential side effects, performance implications, or prerequisites. The list of checks adds some context but lacks transparency about what actually happens during the check.
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 that efficiently lists three check categories. It is easy to parse and front-loaded with the verb. Slightly vague 'diagnostics' could be more specific, but overall it earns its place without waste.
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?
Although the tool has only one parameter and an output schema, the description does not explain what the output means, how projectId is used, or how this differs from sibling tools like report_diagnostics and inspect_project. The mention of 'current revision' is vague and lacks context. For a single-purpose tool, this is under-specified.
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?
The input schema has 0% description coverage, and the description does not mention the projectId parameter at all. It refers to 'current revision' but gives no meaning, format, or relationship to the parameter. The description fails to compensate for the schema's lack of parameter documentation.
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 the specific verb 'Checks' and names concrete resources: scene and camera loading, script syntax, and diagnostics. This clearly communicates the tool's action and scope, though it overlaps slightly with the sibling 'report_diagnostics' without explicit differentiation.
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 like inspect_project or report_diagnostics. The description implies it's for checking project health, but there are no explicit conditions, exclusions, or alternative suggestions.
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 behavioral burden. It discloses the optimistic concurrency condition but omits what happens when baseRevision is stale, whether the write is destructive, any auth requirements, or the shape of the result. 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 a single, front-loaded sentence with no filler. It is efficient and well-structured, though it is slightly under-specified for the tool's complexity.
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 complex nested schema, a sibling-heavy tool set, and no annotations, the description is too thin. It covers only one behavioral aspect and leaves critical context around stale revisions, side effects, and usage relationships unaddressed.
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 description coverage is 0%, and the description adds no explanation for projectId, baseRevision, or the complex nested project object. With three required parameters and a deeply nested schema, the complete lack of parameter prose leaves the agent without semantic guidance beyond raw field names.
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 saves one editor snapshot and adds a meaningful condition about the base revision. It distinguishes from create_project by focusing on saving to an existing project, though it does not explicitly differentiate from save_project_copy. The title provides helpful Three.js context.
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 explicit guidance on when to use this tool versus siblings like save_project_copy, create_project, or apply_scene_changes. The base-revision condition is a behavioral guard, not usage direction; no exclusions or alternatives are mentioned.
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 mention side effects, persistence semantics (e.g., overwrite vs. append), permission requirements, or failure behavior. 'Records' implies a write operation, but important 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, which is concise, but it is under-specified for a tool with this many parameters and side effects. It is not as extreme as a tautology, but it lacks the detail needed to be truly useful, so it falls to a middle score.
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?
The tool involves a write operation with 4 parameters and an output schema, but the description does not explain when to use it, what happens on duplicate revisions, or any constraints beyond the schema. The absence of annotations and minimal description leaves significant gaps for an agent to use it correctly.
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?
The input schema has 4 required parameters with 0% description coverage, and the description does not compensate. It mentions 'errors and warnings' but does not explain their structure or the meaning of projectId and testedRevision beyond what the schema's patterns imply. The description adds negligible value for understanding the parameters.
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: it records Play errors and warnings for a specific project revision. The verb 'Records' and the resource 'errors and warnings' are specific, and 'one exact project revision' sets a clear scope, distinguishing it from sibling tools like inspect_project or check_project.
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 any prerequisites or exclusions. It merely states what the tool does without explaining the appropriate context or how it differs from related operations.
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 that the snapshot is persisted under a new project ID, but does not explain side effects (e.g., whether an existing ID is overwritten or rejected), permissions required, or what 'editor snapshot' means exactly. This is insufficient for a mutation operation.
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, front-loaded sentence with no redundant words. It is concise and easy to scan. However, the verb 'Persists' is slightly less common than 'Saves', which could reduce immediate clarity, but overall it earns high marks for brevity.
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?
Given the complex nested project object, an output schema, and three parameters, the description is far from complete. It omits any mention of return behavior, error cases, or the broader workflow. The tool's purpose is stated, but essential operational context is entirely absent, making it inadequate for a tool of this complexity.
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 description coverage is 0% and the description does not compensate. It only mentions 'new project ID' but provides no explanation of the 'project' or 'sourceProjectId' parameters, how they relate, or what the expected shape of the project object is beyond the schema. The user is left to infer all parameter 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 action ('Persists') and the resource ('editor snapshot') under a new project ID. This distinguishes it from siblings like create_project, which likely creates a new blank project, by emphasizing the copy/save-as semantic.
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 offers no guidance on when to use this tool versus alternatives such as create_project or export_project. It does not mention any exclusions, prerequisites, or scenarios for which this tool is the right choice.
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?
Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It mentions 'revision-checked' and 'bounded', but fails to disclose that operations can be destructive (e.g., remove_object, replace_script) or how conflicts are handled. This is insufficient for a tool that can modify or delete scene elements.
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, compact and front-loaded with the verb. Every word adds meaning without redundancy, making it an ideal length for the information it conveys.
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 complex input schema (five operation types, three required parameters) and an output schema, a one-sentence description is inadequate. It lacks details about operation semantics, error conditions, and the output schema, leaving the agent to rely entirely on the schema without high-level context.
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?
With 0% schema description coverage, the description must compensate for parameter understanding. It adds minimal value: 'scene, script, or project changes' maps loosely to operation types, and 'revision-checked' hints at baseRevision, but it does not explain projectId, baseRevision format, or the operations structure 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 uses a specific verb ('applies') and names the resource ('one revision-checked batch of bounded scene, script, or project changes'), clearly indicating a mutation operation on project content. The phrase 'revision-checked' and 'bounded' distinguishes it from sibling tools like push_project or save_project_copy.
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 gives no explicit guidance on when to use this tool versus alternatives like push_project or save_project_copy. It implies a revision-checked batch context but does not state exclusions, prerequisites, or when it is preferred over other mutation 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 provided, the description must bear full transparency burden. It states the tool 'Returns a bounded JSON export' but does not disclose side effects, authorization requirements, whether it is read-only, or what 'bounded' means. This leaves key behavioral traits unexplained.
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 of 12 words. It is front-loaded with the action ('Returns') and contains no filler or redundant phrasing, making it highly concise.
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 is simple (1 parameter, output schema exists) and the description covers the output's content ('saved project and original assets'). However, it lacks crucial context about error handling, the meaning of 'bounded,' and any side effects, which is especially important given no annotations. This gap prevents a higher score.
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 description coverage is 0%, and the description does not mention projectId or explain its meaning or constraints. Since there is only one required parameter, the description should clarify what it represents, but it does not add any value beyond the schema's pattern field.
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 'Returns' and identifies a clear resource: 'a bounded JSON export containing the saved project and original assets.' This distinguishes it from siblings like pull_project or save_project_copy by emphasizing a full export of project data and assets as JSON.
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?
No explicit guidance on when to use this tool versus alternatives appears. The purpose is implicitly clear (use when you need a project export), but there are no exclusions or mentions of overlapping tools like pull_project, making usage somewhat implied rather than directed.
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. It only states 'Stores' without disclosing side effects, whether the asset replaces existing ones, authorization requirements, or the response format. The term 'bounded' is ambiguous and unexplained, leaving significant behavioral gaps.
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 with a clear verb and resource, containing no fluff or redundant phrasing. It is appropriately front-loaded but would benefit from a bit more detail, which is covered under other dimensions.
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?
The tool has 5 required parameters and no annotations, yet the description does not explain the role of versioning (baseRevision), project scoping (projectId), or data encoding. Although an output schema exists, its content is not shown, so the description still needs to convey outcome expectations. The description is too thin for such a parameter-rich mutation tool.
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 adds no parameter-specific meaning. It does not explain projectId, baseRevision, name, data, or mediaType beyond what the schema already shows. The enum values are partly implied by 'GLB, PNG, or JPEG', but the description fails to clarify how the parameters relate to the operation.
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 'Stores' and identifies the resource ('GLB, PNG, or JPEG asset') and context ('for the current project revision'). This clearly distinguishes it from sibling tools like list_projects or apply_scene_changes, which have different purposes.
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 context by scoping to 'current project revision', but it does not explicitly state when to use this tool vs alternatives, nor give exclusions or prerequisites. No sibling alternatives are mentioned, so guidance is only implicit.
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. It discloses that the tool creates a project and opens the editor, but it does not mention important behavioral aspects such as whether an existing project with the same ID is overwritten, what happens on conflicts, or any side effects beyond opening the editor. The lack of such transparency 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 a single, front-loaded sentence that directly states the core action and the editor-opening side effect. It is concise, with no wasted words or redundant information, earning the highest score for efficiency.
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 essentials for selecting and invoking the tool: it creates a project and opens the editor, and the schema provides required parameter info. However, it lacks details about projectId behavior, template differences beyond names, and any preconditions or return values (though an output schema exists). It is adequate but not rich, leaving several operational questions unanswered.
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, so the description must compensate. It only clarifies the 'template' parameter by naming 'empty' and 'Pong' (which the enum already lists), but it says nothing about the 'title' or 'projectId' parameters, their meaning, or validation behavior. The description adds minimal semantic value beyond the structured 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 uses a specific verb ('Creates') and resource ('Three.js project'), and explicitly mentions the two template options ('empty or Pong'). It clearly distinguishes this tool from siblings like open_editor by including the creation action, and additionally states it opens the editor.
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 the primary use case: creating a new project and opening its editor. However, it does not explicitly state when to use this tool versus alternatives (e.g., open_editor or save_project_copy), nor does it mention any conditions or prerequisites. Usage context is implied but not explicit.
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 present, so the description carries the full burden. It explicitly says 'Reads', indicating a non-destructive operation, and enumerates the data sources. However, it omits details about potential side effects, prerequisites, or how the returned data is structured.
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 lists all major resources inspected, with no unnecessary words. It is front-loaded with the action verb 'Reads'.
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 reads multiple aspects of a project, and an output schema exists to define return values. However, no usage context is provided, and with overlapping sibling tools like check_project and report_diagnostics, the description leaves ambiguity about when this tool is preferred.
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 does not mention the sole parameter projectId. With 0% schema description coverage, the agent receives no description of what projectId represents beyond the schema's name and pattern, and the description fails to compensate.
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 states a specific verb 'Reads' and enumerates the exact resources (scene, script, diagnostics, recent human edit operations), clearly defining the tool's scope. It distinguishes itself from siblings like report_diagnostics, which focuses only on diagnostics.
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 such as check_project or report_diagnostics. The description only states what the tool does, not when it should be invoked.
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 states the scoping context ('configured Three.js project root') and implies a read-only list operation, but it omits details such as ordering, error behavior, or whether any side effects (e.g., refresh) occur. This is minimal but acceptable for a simple list 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 is clear and direct, with no filler or redundancy. Every word contributes to the utility.
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 zero-parameter list tool, the description provides sufficient context about what it lists and where. The existence of an output schema likely covers return value details, so the description need not elaborate. It could mention whether the list is sorted or filtered, but the simplicity keeps it adequate.
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, and the schema confirms this. The baseline for 0 parameters is 4, and the description adds no parameter semantics, which is appropriate since none exist.
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 ('lists') and resource ('projects available in the configured Three.js project root') that clearly identifies the tool's purpose. It does not explicitly differentiate from sibling tools like 'inspect_project' or 'check_project', but the action of listing projects is distinct enough to be understood.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or typical scenarios.
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. 'Opens the editor' is vague—it does not explain what opening entails (e.g., launching a local process, returning a URL, or requiring preconditions like a valid projectId). The behavior remains underspecified.
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 contains the essential information without any filler. Every word earns its place, and there is no ambiguity in structure.
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?
Despite its brevity, the description is largely complete for a simple tool with one parameter and an output schema that presumably covers return details. The word 'existing' implies a prerequisite, and no additional complexity requires deeper disclosure. However, it could specify what the editor opening entails or whether it modifies the project state.
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 provides minimal context for projectId by tying it to 'an existing Three.js project,' which clarifies its role as a project identifier. However, it does not explain the format, how to obtain a valid ID, or any constraints beyond the schema pattern. Schema coverage is 0%, so this slight elaboration adds some value but not enough to fully compensate.
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 the specific verb 'Opens' and identifies the resource as 'the editor for an existing Three.js project.' This clearly distinguishes it from siblings like create_project or export_project by focusing on opening an editor rather than creating or exporting.
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 explicitly states the tool operates on an 'existing' project, signaling that it should not be used for new projects and implying it follows project creation. While no alternative tools are named, the context of siblings and the word 'existing' provide clear usage context.
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:

[![threejs-editor-mcp MCP server](https://glama.ai/mcp/servers/creativedswork/threejs-editor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/creativedswork/threejs-editor-mcp)

Score Badge

Copy to your README.md:

[![threejs-editor-mcp MCP server](https://glama.ai/mcp/servers/creativedswork/threejs-editor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/creativedswork/threejs-editor-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/creativedswork/threejs-editor-mcp'

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