Retrieves a complete Marmoset Toolbag bake project, including Low/High node groups, settings, map options, texture sets, UDIM tiles, and expected output files.
One bake project in full: groups with Low (cage offsets, meshes) and High nodes, settings, maps with options, texture sets, UDIM tiles and the expected output files.
| Name | Required | Description | Default |
|---|---|---|---|
| maps | No | ||
| baker | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered. The description adds useful content scope by listing what the full project includes, but does not disclose error behavior or how the baker parameter resolves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It is dense with returned-content terms, but every item is relevant to what 'full' means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With read-only annotations and an output schema present, the description need not fully document return values. However, it leaves important gaps around how to identify the baker and what the maps flag controls, so it is only adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should clarify both parameters. It mentions 'maps with options' as part of the returned project, which weakly hints at the maps flag, but never explains the baker parameter or whether maps=false excludes maps from the response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource: one bake project retrieved in full, and enumerates the major contents returned (groups, settings, maps, texture sets, UDIM tiles, output files). It implicitly contrasts with baker_list by specifying 'One bake project,' but does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool instead of baker_list or other baker_* tools. The phrase 'One bake project in full' weakly implies detail retrieval, but no conditions, prerequisites, or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.