[Shreyavemana]

Summary

Adds a transform pipeline for the tool catalog, allowing tools/list and tools/call to be rewritten through an ordered chain of transforms. Closes #61.

Changes

• Added the nitrostack/transforms/ package with McpTransform, McpTransformBase, CatalogTransform, TransformPipeline, and TransformContext.
• Added @mcp_app(transforms=[...]) support. List transforms execute in declared order, and resolve_tool supports chaining through next.
• Added re-entrancy support: a synthetic tool can call a real tool through ctx.call_tool(..., caller=name). The issuing transform is skipped, while guards and argument validation are applied to the real tool.
• Unified argument validation through validate_tool_arguments for normal and re-entrant calls.
• Transform exceptions are mapped to JSON-RPC errors without stopping the server.
• Added transform disposal through dispose() during shutdown.
• Skips the transform pipeline when no transforms are configured.

Tests

• Pipeline tests: ordering, next chaining, unknown tools, error mapping, disposal order, and duplicate names.
• Re-entrancy tests: transform skipping and scoped tool calls.
• App-level tests: tools/list byte-for-byte parity against a pre-change baseline across legacy, auto, and modern protocol eras; transform composition; failing transforms; and shutdown behavior.
• Targeted test results: 16 passed across test_transforms_pipeline.py, test_transforms_reentrancy.py, and test_transformsapp.py.
• Full-suite status: one failure remains in tests/test_readme_examples.py::test_building_blocks_run. The AuditLog receives A1 twice instead of once. This appears to be a duplicate event/listener invocation and still needs investigation. Full-suite parity with main has not yet been established.

Dependency

Depends on #22.

[AadarshM07]

Hi @Shreyavemana , I believe this implementation is designed with the assumption that the JSON-RPC sidecar will be removed as part of issue #22. while the transform pipeline itself operates at the McpApplication level and doesn't directly depend on the sidecar, I think it would be better to merge and validate #22 first, then test this PR against the updated architecture before merging it. This would help ensure the transform pipeline integrates correctly with the official MCP handler. what do you think ?

[AadarshM07]

Hi @Shreyavemana, I think #88 brings in all the commits from this branch and is closely related to issue #61 . To keep things simple and avoid intermediate issues. I will review #88 directly and lets later merge that one!

cc: @manish-wekan