Skip to main content
Glama
natl-set

ANTLR4 MCP Server

by natl-set

preview-tokens

Preview how ANTLR4 lexer rules tokenize input text. Test grammar changes, debug tokenization issues, and verify rule matches instantly.

Instructions

Preview how input text would be tokenized by lexer rules. Test grammar changes instantly!

šŸš€ Native ANTLR4 Support: Automatically uses native ANTLR4 runtime if available for 100% accurate tokenization including:

  • āœ… Lexer modes (pushMode, popMode)

  • āœ… Semantic predicates ({...?})

  • āœ… Actions ({...})

  • āœ… All ANTLR4 features

Falls back to simulation if ANTLR4 is not installed (works for simple grammars without modes/predicates).

When to use:

  • Test if lexer rules match input as expected

  • Debug tokenization issues (especially with complex grammars!)

  • Verify grammar changes work correctly

  • Learn how ANTLR4 tokenizes input

Setup for 100% accuracy (optional):

  1. Install Java: brew install openjdk

  2. Install ANTLR4: wget https://www.antlr.org/download/antlr-4.13.1-complete.jar

  3. Set env: export ANTLR4_JAR=/path/to/antlr-4.13.1-complete.jar

How it works:

  • Native mode: Compiles and executes actual ANTLR4 lexer (100% accurate)

  • Simulation mode: Best-effort tokenization (works for ~70% of grammars)

Example - Test basic tokenization: input: "x = 42;"

Example - Test with complex lexer (Palo Alto): from_file: "PaloAlto_lexer.g4" load_imports: true input: "set user-id-collector enable-mapping-timeout 1"

Example - Test specific rules only: input: "x + y * 2" rules_to_test: ["ID", "PLUS", "TIMES", "INT"]

Returns:

  • List of tokens with types and values

  • Character positions (start, end, line, column)

  • Channel information for channeled tokens

  • Errors for unmatched characters

  • Mode indicator (šŸš€ Native or āš ļø Simulation)

  • Feature warnings if simulation used

Limitations: āŒ Lexer modes not supported āŒ Semantic predicates not evaluated
āŒ Actions not executed āš ļø Fragment rules (basic support) āš ļø Complex patterns (best-effort)

Alternative: For complex grammars, use test-parser-rule which tests parser rules without full lexer simulation.

Note: This is a simplified simulation. For 100% accuracy, use ANTLR4 tooling.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesInput text to tokenize. Can include newlines and special characters.
from_fileNoOptional: path to a grammar file to read
rules_to_testNoOptional: Test only specific lexer rules (by name). Useful for focused testing.
show_positionsNoIf true, show detailed position information (line, column, start, end) for each token
grammar_contentNoThe ANTLR4 grammar file content with lexer rules
Behavior5/5

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

With no annotations, the description carries full behavioral burden. It clearly explains native ANTLR4 mode versus simulation fallback, details simulation limitations (lexer modes, predicates, actions), and describes return values including feature warnings and mode indicators. No contradictions.

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 well-structured with clear sections and front-loaded purpose, but it is verbose with emojis, repeated limitations, and extensive setup instructions. It could be trimmed by ~30% without losing essential information.

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?

The description covers behavior, setup, examples, return format, limitations, and alternatives. Since there is no output schema, the detailed Returns section is essential and fully compensates for that gap.

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 schema covers 100% of parameters, so baseline is 3. The description adds rich examples for input, from_file, and rules_to_test, clarifying usage beyond dry schema definitions. However, one example references 'load_imports: true', which is not an actual parameter, creating minor confusion.

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 opens with a specific verb and resource: 'Preview how input text would be tokenized by lexer rules.' It also explicitly distinguishes itself from the sibling tool test-parser-rule, stating it tests parser rules without full lexer simulation.

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?

A dedicated 'When to use' section lists concrete scenarios such as testing rule matches, debugging tokenization, verifying grammar changes, and learning ANTLR4. It also provides an explicit alternative: 'For complex grammars, use test-parser-rule.'

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

Install Server

Other Tools

Latest Blog Posts

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/natl-set/antlr4-mcp'

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