compose-bridge

by TechsOneAi

Overview Schema Source Related Servers Discussions Admin

Python

Local

This server has been deprecated

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

get_all_token_groups

Read-onlyIdempotent

Lists all semantic design token groups in a Jetpack Compose project so you can inspect high-level grouping across design system objects without reading individual tokens.

Instructions

Read-only. Returns ALL semantic token groups in the project (e.g., 'Actions', 'Dashboard', 'Settings').

What it does: Lists all token groups discovered across design system objects.
When to use: To inspect the high-level semantic grouping of design tokens.
When NOT to use: Use list_tokens for individual tokens. Groups are based on object declarations in AppStrings/DesignSystem.
Side effects: Read-only. No files modified.
Parameters: None.
Returns:
  JSON string with group names, member token counts, and parent objects.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026
RemovedOct 22, 2026
First observedv0.1.0Oct 19, 2026

TDQS

A4.4/5.0

Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, and the description largely restates this ('Read-only', 'Side effects: Read-only. No files modified'), which earns no extra credit. The one genuine addition is the derivation rule — groups come from object declarations in AppStrings/DesignSystem — which explains what 'group' means and why the set is unfiltered, but no mention of ordering, scale limits, or whether results can be stale.

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?

Well front-loaded with the key fact ('Returns ALL semantic token groups') in the first line and cleanly sectioned by what/when/when-not/returns. The only waste is the triple restatement of read-only behavior ('Read-only' lead, the 'Side effects' line, and the annotations themselves), which could be collapsed to one clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, annotated, output-schema-backed read tool, the description covers purpose, scope ('ALL', unfiltered), group derivation, exclusion against list_tokens, and a return summary. Nothing an agent needs to decide or invoke correctly is missing.

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 takes zero parameters, which is the baseline-4 case; the description confirms 'Parameters: None' and does not mislead about any implicit filtering. No further parameter meaning is needed or possible.

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: 'Returns ALL semantic token groups in the project', and grounds the concept with concrete examples ('Actions', 'Dashboard', 'Settings'). It also distinguishes itself from the closest sibling by naming list_tokens as the per-token alternative, so an agent can route correctly 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?

Explicitly gives a when-to-use ('inspect the high-level semantic grouping of design tokens') and a when-NOT-to-use that names the alternative tool (list_tokens for individual tokens). The selection rule between the two siblings is fully specified, leaving nothing to inference.

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