Scan this Storybook file, generate a markdown file with below mentioned sections
## Component Name

## Description - this should be 3-4 line description that is understandable by LLMs and MCP clients to pick

## TypeScript Types - Add short description that these types are the props that the component accepts so that the LLMs pick this up properly. Get all the types required for this component and its subcomponents. Imagine You're a consumer who's trying to use {ComponentName} component along with its subcomponent so in order for you to know what {ComponentName} accepts as props and what props its subcomponents accepts you need to have all the types to be in one place for reference. Do not generate or inference types yourself, it already exists under types.ts or {componentName}tokens.ts file. In addition, scan the types in {ComponentName}'s file and also subcomponents' file of {ComponentName} for types. Never pick types from `.stories` file. Preserve the declaration eg: if its declared as `type` preserve it, if its declared as `interface` preserve it. If there are union types don't skip them, they shall be included as well along with types for eg: if `type {ComponentName}Props` has `TestID`, `StyledPropsBlade` or `DataAnalyticsAttribute`. Do not pick types that start with `_typename` or part of components that start with `_ComponentName` those are private types/components not be exposed to consumer and meant for internal purposes. Do not add types to the markdown that start with `Base*` eg: `BaseSomeProps` or `BaseSomeComponentName` or `BaseSomeTypeName` these are again internal types and components not useful for end consumers.

## Example - Create usage examples by clubbing multiple use cases like prop variations with all the props for {ComponentName} component. Follow best coding practices. Create code that follows accessibility guidelines and uses the right accessibility props defined by components. Create ONE comprehensive example per distinct use case, with each example showing multiple props combined in practical ways. Don't create multiple examples showing similar functionality with minor variations. Focus on showing how different prop combinations work together in real-world scenario for example: default selection, disabled cases, prefix prop, suffix prop, type prop, sizes prop, formatting props, color prop, variant prop, accessibility props etc in single clubbed examples so we don't bloat examples. Put core features and props in one example component and not multiple components within one example component. Do not ever use comments `{/* some comment *}` or headings to merge variations in one example. Split examples whenever necessary in their own sections with heading and short description of what each example does. All the examples must show the import statements too required for creating that example. Use Box component only wherever its required and necessary. Focus on comprehensive usage rather than isolated prop demonstrations. Create examples that focuses more on this components use cases and use other components only as supporting components whenever required. This will be fed to LLMs in future when the user ask to build something that involves this component. This example will just act as the blueprint and then referring the types and prompt of user the LLMs will be able to create the required example prompted by a user. Do not pick components that start with `_something` those are private components and never exposed to consumer and meant for internal purposes. All the imports that start with `~/something` should be replaced with named exports of `@razorpay/blade/something` eg: `~components/*` shall be replaced with named absolute imports of `@razorpay/blade/components`. 

Do this only for {ComponentName} component right now and save it under a directory packages/blade-mcp/knowledgebase/components/{ComponentName.md}. Do not touch any other file/directory in this project.