compose-bridge

Overview Schema Source Related Servers Discussions Admin

set_design_file_mapping

DestructiveIdempotent

Persist custom Kotlin design-file paths for colors, dimensions, or strings in .composebridge/config.json to resolve NEEDS_MANUAL_MAPPING and lock target token files.

Instructions

Sets a designated design/registry file in .composebridge/config.json for a token type.

When to use:
- Call when ComposeBridge stops with NEEDS_MANUAL_MAPPING because design system files are in non-standard paths.
- Call to lock designated target files for colors, dimensions, or strings.

When NOT to use:
- Do not use if the project uses standard design file locations (e.g., Color.kt, AppStrings.kt).
- Do not use for reading existing token mappings (use get_design_file_mappings instead).

Side effects:
- Modifies .composebridge/config.json on disk to persist file mappings.

Args:
    token_type: 'color', 'dimension', 'string', or 'all'.
    file_path: Relative path to the Kotlin file (e.g. 'composeApp/src/commonMain/kotlin/.../Color.kt').
    project_root: Optional path to project root.

Input Schema

Name	Required	Description	Default
`file_path`	Yes
`token_type`	Yes
`project_root`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered; the description still adds the concrete side effect that .composebridge/config.json is modified on disk. It does not state whether an existing mapping for the same token_type is silently overwritten, which is the main remaining behavioral 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 purpose sentence is front-loaded, and the labeled sections make scanning fast. The Args block repeats some of the schema, but given the zero coverage that repetition is functional rather than waste.

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 destructive config-mutating tool the description covers trigger, exclusions, alternative, and disk side effect, and an output schema exists to explain return values. Only the overwrite/conflict semantics of re-mapping an already-mapped token type are left unstated.

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 carry the parameter meaning, and it largely does: it supplies the accepted token_type values ('color', 'dimension', 'string', 'all') that the schema does not enumerate, gives a relative-path example for file_path, and marks project_root optional. It stops short of stating path constraints or validation rules for file_path.

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?

Names a specific verb and resource (sets a design file mapping) and pinpoints the artifact it writes (.composebridge/config.json) for a given token type. An agent can distinguish it from get_design_file_mappings without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit 'When to use' section tied to a concrete trigger (NEEDS_MANUAL_MAPPING from ComposeBridge) and a 'When NOT to use' section that names both the excluded condition (standard file locations) and the alternative sibling (get_design_file_mappings).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.