Skip to main content
Glama
Sign In
compose-bridge

compose-bridge

by TechsOneAi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local
This server has been deprecated

Rebranded to ComposeLint AI. Repository has been moved to TechsOneAi/ComposeLintAI.

set_text

Destructive

Edits UI text strings in Kotlin Compose files, automatically migrating hardcoded text to BridgeTextRegistry for live preview.

Instructions

DESTRUCTIVE: Modifies .kt files. Surgically edit text content with automatic BridgeTextRegistry wrapping.

What it does: Modifies .kt files. Auto-migrates hardcoded text to BridgeTextRegistry for live preview.
When to use: When editing UI text strings, whether defined in AppStrings or hardcoded in Composable Text("...") elements.
When NOT to use: Do not use for colors or dimensions (use set_token or add_token).
Side effects: DESTRUCTIVE: Modifies source code on disk. Requires approve_file_changes before changes take effect in git. Can be reverted via reject_file_changes.
Parameters:
  - token_name: reference key (e.g., 'AppStrings.Dashboard.title') OR exact old text content to replace.
  - new_value: The new text string to set.
  - file_path: relative path to source file (e.g., 'QuickActionsWidget.kt' or 'ui/theme/AppStrings.kt').
  - line: optional line number for disambiguation if text appears multiple times.
Returns:
  JSON string with success status, old_text, new_text, and modified file location.

Input Schema

NameRequiredDescriptionDefault
lineNo
file_pathNo
new_valueYes
token_nameYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Addedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds the real workflow consequences: writes on disk, requires approve_file_changes to land in git, and is revertible via reject_file_changes. It also discloses non-obvious auto-migration side effects. It does not mention scope of the edit when file_path is omitted, which keeps it from a 5.

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?

Labeled sections (What it does / When to use / When NOT / Side effects / Parameters / Returns) make it scannable and front-loaded with the DESTRUCTIVE warning. Minor redundancy: 'Modifies .kt files' appears twice in the first three lines.

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?

Output schema exists, yet the returns line still usefully names success status, old_text, new_text, and file location. The one real gap is that file_path is optional but the description never says what happens when it is omitted (search scope across files), which matters for a destructive edit.

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?

Schema description coverage is 0%, so the description carries the full burden and does: token_name is explained as either a reference key or literal old text, new_value as the replacement, file_path with path examples, and line as an optional disambiguator for repeated text. The dual-mode token_name semantics are otherwise undiscoverable.

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?

States a specific verb and resource ('Surgically edit text content', 'Modifies .kt files') plus the automatic BridgeTextRegistry wrapping behavior. It clearly distinguishes itself from the token-oriented siblings by declaring text strings as its domain.

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?

Gives an explicit 'When to use' covering both AppStrings-defined and hardcoded Text("...") cases, and an explicit 'When NOT to use' routing colors/dimensions to set_token or add_token. This is exactly the routing an agent needs against a large sibling set.

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

Deploy Server

Other Tools