[josemontespg]

Summary

Many MCP servers return list data only as text, usually as records of Key: value lines separated by blank lines. This PR adds two data functions for that output. split cuts the text of the callMcpTool payload into records. regexCapture turns each record into its capture groups, or null when it does not match. Both take a single string or an array of strings, so a chain like transformData(regexCapture(split(...))) turns a text result into rows without any client code.

regexCapture patterns use a portable subset that every renderer can implement: JavaScript syntax without lookahead, lookbehind or backreferences. isPortableRegex checks this before the isSafeRegex check for catastrophic backtracking, and any pattern that fails either check raises an A2uiExpressionError. The catalog ships its own copy of isSafeRegex (src/functions/safe_regex.ts, backed by redos-detector, the same check as the basic catalog's regex function), so @a2ui/web_core does not have to export it.

The READMEs now describe the four data functions as a closed set and explain why each one is included. They also show how a host adds its own parser in a catalog of its own and calls it with that catalog's catalogId.

Changes

• src/functions/split.ts, src/functions/regex_capture.ts: SplitApi, SplitImplementation, RegexCaptureApi and RegexCaptureImplementation. The pattern description states the portable subset.
• src/functions/regex_support.ts: isPortableRegex skips escaped characters and the contents of character classes. compileSafeRegex runs both checks and caches compiled patterns. mapTextValue does the string-or-array mapping.
• src/functions/safe_regex.ts, package.json: the isSafeRegex copy and its redos-detector dependency (already in yarn.lock through @a2ui/web_core).
• src/catalog.ts, src/index.ts, catalogs/mcp/v1/catalog.json: register, export and declare split and regexCapture.
• catalogs/mcp/v1/examples/mcp-text-tool-result.json: a Tavily-style search. The button calls split on \n\n and regexCapture with ^Title: (.*)\nURL: (.*), then transformData drops the records that did not match, names the fields and writes them to /results.
• Tests: split.test.ts, regex_capture.test.ts, regex_support.test.ts (portable and non-portable patterns, including escapes and character classes), safe_regex.test.ts (ported from @a2ui/web_core), and the text example's button in catalog.test.ts.
• typescript/catalogs/mcp/README.md: a data functions section with the argument table, the regex rules, why each function is included, and a custom parseCsv function in a host catalog. catalogs/mcp/README.md has a short version.
• CHANGELOG.md: adds split and regexCapture to the package's unreleased entry.

Verification

• yarn workspace @a2ui/catalog-mcp run test: 220 node tests and 222 karma tests pass, and the test type check is clean.
• yarn workspace @a2ui/catalog-mcp run lint: no errors.
• uv run python3 specification/v1_0/test/run_tests.py: 179 passed.
• I type-checked the README's custom function snippet against @a2ui/web_core.
• ./scripts/fix_format.sh: clean.

[gemini-code-assist]

Code Review

This pull request adds three new text-processing data functions (split, regexCapture, and regexReplace) to the A2UI MCP catalog, enabling surfaces to parse and shape plain text outputs from headless MCP tools. It includes schema updates, TypeScript implementations with safe regular expression compilation, comprehensive unit tests, and a practical example of directory listing parsing. The review feedback highlights two valuable improvements: ensuring Unicode-aware character splitting in the split function when the separator is empty, and wrapping the isSafeRegex check inside the try-catch block in regex_support.ts to prevent unhandled crashes during expression evaluation.

[ditman]

Requesting changes for the same reason as #3573 (and per #3153 / #3171): split, regexCapture, and regexReplace are general string/regex utilities rather than MCP primitives and should not be part of catalogs/mcp/v1/catalog.json or @a2ui/catalog-mcp. Please keep them in samples/community/mcp/a2ui-over-mcp-filesystem/client/functions/ where they are used.

[wrenj]

Requesting changes for the same reason as #3573 (and per #3153 / #3171): split, regexCapture, and regexReplace are general string/regex utilities rather than MCP primitives and should not be part of catalogs/mcp/v1/catalog.json or @a2ui/catalog-mcp. Please keep them in samples/community/mcp/a2ui-over-mcp-filesystem/client/functions/ where they are used.

Hi David, I discussed this with Jose and we need these functions to parse MCP responses. This catalog is being added to GE and is already wired up (with the functions) in the 1P Composer, Chat Canvas, and some new projects. I don't think we want to make shared libraries that require every client to make a custom catalog that rolls their own utility functions, it breaks portability and makes for bad devex (we'd basically have a README.md in the MCP Catalog saying copy these utility functions from samples and put them in your own catalog). The material3 catalog for instance has a ton of support functions (regex, dateLessThan) that could arguably fit better elsewhere but we just ship as part of that catalog. LMK what you think. thanks

[ditman]

we need these functions to parse MCP responses.

@wrenj I can be convinced that some functions that we're adding to this catalog are warranted (like allowing json selectors/transformers into a random data structure), but others, like "split" not so much. Why is "split" needed but not "trim" or "length" or... you name it? Where does this stop? Do we need to add as many functions as requested by users who "can't launch their startup" without them, instead of having something that lets users inject their own business logic?

This catalog is being added to GE and is already wired up (with the functions) in the 1P Composer, Chat Canvas, and some new projects.

That's OK, catalogs are composable, and apps should be able to add whatever parsing functions they need. For example, what if they need "parseProtoBuf" or "parsePrivateProtocol"? Should those functions also be part of the open source catalog? Probably not, but the assortment of functions that are adding to this catalog is so random that it makes it very hard to say "no" to other requests down the line.

The material3 catalog for instance has a ton of support functions (regex, dateLessThan) that could arguably fit better elsewhere but we just ship as part of that catalog.

Since you mention "regex", I think that's a great argument against adding utility functions like "regexCapture" to this catalog. Now for users that mix that catalog and this one. Are they going to end up with two similar-but-not-quite-the-same "regex" functions with different functionality. I'd imagine that more common functions (like "split", for example) may end showing up many times.

If functions "could arguably fit better elsehwere", we should find that place.

Anyways, onwards.

[ditman]

Disagree and commit! Ship it!

[ditman]

wouldn't this be much, much more ergonomic if users could inject a "handleSearchResults" function that encapsulates all this code-as-JSON in actual code?

[ditman]

Ah thanks for adding this note, I missed something like this in the prior PR!