@ebitex/content-mcp 0.5.137 → 0.5.140

package/dist/resources/helpCorpus.generated.js

@@ -51,7 +51,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-providers",
         "title": "Content providers",
-        "body": "# Content providers\n\nContent providers let you bring in read-only content from an external system — a product catalog,\na digital asset manager, anything a plugin has been built for — so it sits alongside your own\nComponents everywhere you'd normally reference one: Reference fields, Presentation bindings,\npublished pages.\n\n## Registering a provider\n\nOpen **Plugins** under **Settings** in the app navigation. Registering requires a plugin to\nalready be **activated** for your organization (an administrator does this from Hub's plugin\nsettings first — this page just registers an *instance* of an already-activated plugin).\n\n1. Choose the plugin from the **Plugin** dropdown.\n2. Give it a **provider key** — a short, lowercase, hyphenated name (e.g. `example-products`).\n   This becomes part of every reference stored against items from this provider, so **choose it\n   once and don't expect to rename it later**; changing your mind means unregistering and\n   registering again under a new key.\n3. Fill in whatever configuration the plugin asks for — this varies per plugin, and any field\n   marked sensitive (an API key, say) is write-only: once saved, you'll only ever see that it's\n   set, never the value itself.\n4. Set a **cache TTL** — how long (in seconds) a fetched item is reused before Content checks the\n   external system again when serving published content. Lower values mean fresher data with more\n   load on the external system; higher values mean better performance but slower-to-appear\n   changes.\n5. Select **Register**. Content contacts the provider and pulls in the Contracts (content types)\n   it describes — you'll see them show up in the Contract library, badged with the provider's\n   name.\n\nIf your organization authors in more than one environment and a provider is already registered in\none of them, use **Copy from another environment** instead of registering from scratch — pick the\nsource environment and the provider key, and its full configuration (including anything sensitive)\ncomes along without you re-entering it. See [content-environments.md](content-environments.md).\n\n## Using provider content\n\nWherever you can pick a Component — a Reference field, or a Presentation's bound Component — the\npicker now shows a row of tabs: **Core** (your own content) plus one tab per registered provider.\nSwitch tabs to browse or search that provider's items; not every provider supports search, in\nwhich case the search box is disabled for that tab. Once picked, an external item behaves like any\nother reference: you can still add your own decoration on top of it (a headline, a promotional\nlabel — whatever the provider's Contract declares as an editable-here field) without touching the\nexternal system at all.\n\nIf an external item is later removed on the provider's side, or the provider becomes temporarily\nunreachable, the reference shows as unresolved rather than blocking your save — you can fix it\nwhenever the item (or the provider) is available again.\n\n## Refreshing and unregistering\n\nProvider Contracts don't update automatically — select **Refresh Contracts** on a registration\nwhenever the external system's own content types have changed. Refreshing can add new Contracts,\nupdate existing ones, and remove ones no longer described (removal is blocked if something still\ndepends on it — a Reference field constraint or a Template's supported-Contracts list — with the\nusages listed so you can address them first).\n\n**Unregister** removes a provider entirely, along with its synced Contracts — blocked the same\nway if any content still references it. Once you confirm, existing references to that provider\nkey become permanently unresolved.\n\n## Permissions\n\nRegistering, updating, refreshing, and unregistering providers requires its own \"Manage Content\nproviders\" permission — ask an Owner or administrator to grant it if the register/refresh/\nunregister actions aren't available to you. Anyone with organization membership can view\nregistered providers and use them in a picker.\n"
+        "body": "# Content providers\n\nContent providers let you bring in read-only content from an external system — a product catalog,\na digital asset manager, anything a plugin has been built for — so it sits alongside your own\nComponents everywhere you'd normally reference one: Reference fields, Presentation bindings,\npublished pages.\n\n## Registering a provider\n\nOpen **Plugins** under **Settings** in the app navigation. Registering requires a plugin to\nalready be **activated** for your organization (an administrator does this from Hub's plugin\nsettings first — this page just registers an *instance* of an already-activated plugin).\n\n1. Choose the plugin from the **Plugin** dropdown.\n2. Give it a **provider key** — a short, lowercase, hyphenated name (e.g. `example-products`).\n   This becomes part of every reference stored against items from this provider, so **choose it\n   once and don't expect to rename it later**; changing your mind means unregistering and\n   registering again under a new key.\n3. Fill in whatever configuration the plugin asks for — this varies per plugin, and any field\n   marked sensitive (an API key, say) is write-only: once saved, you'll only ever see that it's\n   set, never the value itself.\n4. Set a **cache TTL** — how long (in seconds) a fetched item is reused before Content checks the\n   external system again when serving published content. Lower values mean fresher data with more\n   load on the external system; higher values mean better performance but slower-to-appear\n   changes.\n5. Select **Register**. Content contacts the provider and pulls in the Contracts (content types)\n   it describes — you'll see them show up in the Contract library, badged with the provider's\n   name.\n\nIf your organization authors in more than one environment and a provider is already registered in\none of them, use **Copy from another environment** instead of registering from scratch — pick the\nsource environment and the provider key, and its full configuration (including anything sensitive)\ncomes along without you re-entering it. See [content-environments.md](content-environments.md).\n\n## Using provider content\n\nWherever you can pick a Component — a Reference field, or a Presentation's bound Component — the\npicker now shows a row of tabs: **Core** (your own content) plus one tab per registered provider.\nSwitch tabs to browse or search that provider's items; not every provider supports search, in\nwhich case the search box is disabled for that tab. Once picked, an external item behaves like any\nother reference: you can still add your own decoration on top of it (a headline, a promotional\nlabel — whatever the provider's Contract declares as an editable-here field) without touching the\nexternal system at all.\n\nIf an external item is later removed on the provider's side, or the provider becomes temporarily\nunreachable, the reference shows as unresolved rather than blocking your save — you can fix it\nwhenever the item (or the provider) is available again.\n\n## Registering your Assets library\n\nIf your organization uses Assets, register it like any other provider and pick **ebitex Assets** as\nthe plugin. It asks for one thing, an **API key**. Mint that key in Assets under **Settings →\nChannels**, on the channel you want this registration to see. What the key can see is decided there,\nnot in Content: the channel's folders, its categories, and whether private assets are included. Use a\nseparate registration, with its own channel's key, for each site or audience that should see a\ndifferent slice of the library.\n\nOnce registered, a Reference field can be limited to **Image**, **Video** or **Document**, and the\npicker's Assets tab shows only those, with a thumbnail and a line such as \"Image · 1600×900 · de\nrendition\". A field that lists an Assets type must allow **Reference** (not only inline). See\n[Assets](../assets/library.md) for the library itself.\n\nA change you make in Assets reaches published pages without republishing, after a short delay: the\ncache TTL above plus the delivery cache. Deleting an asset turns every reference to it into an\nunresolved one.\n\n## Refreshing and unregistering\n\nProvider Contracts don't update automatically — select **Refresh Contracts** on a registration\nwhenever the external system's own content types have changed. Refreshing can add new Contracts,\nupdate existing ones, and remove ones no longer described (removal is blocked if something still\ndepends on it — a Reference field constraint or a Template's supported-Contracts list — with the\nusages listed so you can address them first).\n\n**Unregister** removes a provider entirely, along with its synced Contracts — blocked the same\nway if any content still references it. Once you confirm, existing references to that provider\nkey become permanently unresolved.\n\n## Permissions\n\nRegistering, updating, refreshing, and unregistering providers requires its own \"Manage Content\nproviders\" permission — ask an Owner or administrator to grant it if the register/refresh/\nunregister actions aren't available to you. Anyone with organization membership can view\nregistered providers and use them in a picker.\n"
     },
     {
         "slug": "content-streams",
@@ -61,7 +61,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-taxonomy",
         "title": "Taxonomy",
-        "body": "# Taxonomy\n\nOrganize your content with named classification trees — usable both as tags on Components,\nExperience pages, and Contracts (for findability and bulk operations) and as a field type your\nContracts can use directly.\n\n## CategoryGroups and Categories\n\nA **CategoryGroup** is the root of one tree — \"Topics,\" \"Regions,\" \"Campaigns.\" Open **Taxonomy**\nunder **Configure** in the app navigation to manage groups and their trees.\n\nA **Category** is one node in a group's tree. Each category has:\n\n- A **key** (used in paths and safe to keep even if you change the display value)\n- A **display value** — localizable, like any other text in the app\n- **Selectable** — turned off, a category becomes a purely structural branch: something you can\n  nest other categories under, but never assign to content directly. Use this for organizing\n  headings like \"Seating\" that shouldn't themselves be a tag.\n\nA category can be nested under another category in the same group, to any depth. You can't delete\na category (or turn off its Selectable flag) while it still has child categories, tags, or field\nvalues referencing it — you'll see how many places reference it if you try.\n\n### Metadata\n\nWhen creating a group, you can optionally attach a **metadata Contract** — the same kind of\nstructure definition you use for content, but describing extra information every category in this\ngroup should carry (an icon name, a color, a short blurb). If a group has a metadata Contract,\nevery category in it gets a metadata form to fill in.\n\n## Tagging content\n\nOpen any Component (under its **Settings** tab), Experience page, or Contract (under its\n**General** tab) and find the **Categories** panel. **Add tag…** opens a picker scoped to one\ngroup at a time (or a specific group, if the page only allows one); pick any selectable category\nand it's added. Tags are separate from any Category field value the item's Contract might also\nhave — think of tags as sticky notes for finding and grouping things, not part of the content\nitself. Tagging a Contract needs the same permission that lets you edit the Contract at all;\nTemplates can't be tagged yet.\n\n## Filtering by category\n\nThe Component library has a **Filter by category** control — pick a category and the list narrows\nto everything tagged with it (or a category nested under it). Select several items from a filtered\nlist and use **Publish N selected…** to publish them all together through the usual publish dialog,\nwhich shows the combined set of everything each selected item depends on.\n\nThe Experience page has the same **Filter by category** control on its site tree. Because the tree\nonly loads a branch's children when you expand it, picking a category automatically expands every\nancestor branch needed to reach each matching page, highlights the matches, and dims everything\nelse that's visible without hiding it — so you can still see where a match sits relative to the\nrest of the site. Clearing the filter leaves the tree as you left it.\n\n## Filtering which Contract you pick\n\nWhen adding new content from an Experience page's payload editor — \"New Component\" or \"Create\ninline\" — the Contract picker offers a **Filter by category** button. Pick a category and the\nchoices narrow to Contracts tagged with it; **Clear** brings back the full list. This is a\nconvenience for a large Contract library — it defaults to showing every eligible Contract, and you\ncan always clear the filter to reach one that isn't tagged.\n\n## Using a Category field on a Contract\n\nWhen building a Contract, add a field with type **Category**. In its settings, you can restrict\nwhich CategoryGroup(s) the field accepts — leave it empty to allow any group. In the Component\neditor, that field shows a **Choose…** button opening the same category picker; the chosen\ncategory displays as its full path (e.g. `topics/tech/ai`).\n\n## What happens when you rename or move a category\n\nRenaming a category, or moving it to a different parent, updates everywhere it's referenced\nimmediately — no republishing needed. What *does* require republishing is a **tag added after\npublish**: a Component's set of published categories is frozen at publish time, exactly like its\ncontent. If you tag something new and want that reflected in delivered results, publish it again.\n\n## External taxonomy\n\nIf your organization has registered a content provider that also supplies taxonomy, its groups and\ncategories appear in the picker and the Taxonomy page alongside your own — marked **synced** and\nread-only. They work identically to your own categories everywhere except editing: you can tag\ncontent with them and use them in Category fields, but changing them happens on the provider's own\nside, refreshed the same way its other content is.\n"
+        "body": "# Taxonomy\n\nOrganize your content with named classification trees — usable both as tags on Components,\nExperience pages, and Contracts (for findability and bulk operations) and as a field type your\nContracts can use directly.\n\n## Where the vocabulary lives\n\nThe category groups and categories themselves — the **vocabulary** — belong to your organization, not\nto Content alone: the same \"Topics\" or \"Regions\" that classify a Component can classify an asset in\nAssets. They are managed in **Hub › Taxonomy** (see the Hub guide), where each group shows where it is\nin use.\n\nContent's own **Taxonomy** page, under **Configure**, answers a different question: **which of the\norganization's groups can editors use in this environment?** A group is only visible here once it has\nbeen added, and other environments — including a sub-tenant's — never see a group nobody added to\nthem. The page has two lists:\n\n- **In this environment** — the groups editors can tag with and pick in Category fields here, with\n  how many categories each has and whether it carries a metadata Contract here. **Remove from this\n  environment** hides a group from pickers again; it is disabled, with the reason, while anything\n  here is still tagged with one of its categories, a Category field value still names one, or a\n  Category field on a Contract restricts to the group. Removing never deletes the group, its\n  categories, or anything already tagged.\n- **Available to add** — the organization's groups not yet in use here. **Add to this environment**\n  makes one usable; optionally give it a metadata document here at the same time (below).\n\nAdding and removing needs the **Manage Content taxonomy** permission (`content.taxonomy.manage`).\n**New group** creates a group in the organization vocabulary *and* adds it here in one step; because\nit writes the vocabulary it also needs `platform.taxonomy.manage`.\n\n### Editing the tree from Content\n\nBelow the two lists, the page shows the vocabulary for every group added here — the same tree editor\nHub uses. If you hold `platform.taxonomy.manage` you can add, rename, move and delete categories right\nthere; a change applies in every environment and app at once. Without it the tree is read-only, and\neach button says so.\n\n### Missing a group?\n\nIf the group you expect is not in the category picker, it has not been added to this environment.\nSomeone with `content.taxonomy.manage` sees a **Manage groups in this environment** link at the\nbottom of the picker that goes straight to the Taxonomy page; everyone else simply does not see the\ngroup, which is the point.\n\n## CategoryGroups and Categories\n\nA **CategoryGroup** is the root of one tree — \"Topics,\" \"Regions,\" \"Campaigns.\"\n\nA **Category** is one node in a group's tree. Each category has:\n\n- A **key** (used in paths and safe to keep even if you change the display value)\n- A **display value** — localizable, like any other text in the app\n- **Selectable** — turned off, a category becomes a purely structural branch: something you can\n  nest other categories under, but never assign to content directly. Use this for organizing\n  headings like \"Seating\" that shouldn't themselves be a tag.\n\nA category can be nested under another category in the same group, to any depth. You can't delete\na category (or turn off its Selectable flag) while anything in any app still references it — the\ndialog lists every usage, per app and environment, so you can decouple them first.\n\n### Metadata\n\nWhen adding a group to an environment (or creating one from Content), you can optionally attach a\n**metadata Contract** — the same kind of structure definition you use for content, but describing\nextra information every category in this group should carry *in this environment* (an icon name, a\ncolor, a short blurb). If a group has a metadata Contract here, every category in it gets a\n**Metadata** editor in the tree. Metadata is Content's and per environment: the organization's\nvocabulary carries none, and removing the group from an environment removes its metadata Contract and\ndocuments there.\n\n## Tagging content\n\nOpen any Component (under its **Settings** tab), Experience page, or Contract (under its\n**General** tab) and find the **Categories** panel. **Add tag…** opens a picker scoped to one\ngroup at a time (or a specific group, if the page only allows one); pick any selectable category\nand it's added. Only groups added to the current environment are offered. Tags are separate from\nany Category field value the item's Contract might also have — think of tags as sticky notes for\nfinding and grouping things, not part of the content itself. Tagging a Contract needs the same\npermission that lets you edit the Contract at all; Templates can't be tagged yet.\n\n## Filtering by category\n\nThe Component library has a **Filter by category** control — pick a category and the list narrows\nto everything tagged with it (or a category nested under it). Select several items from a filtered\nlist and use **Publish N selected…** to publish them all together through the usual publish dialog,\nwhich shows the combined set of everything each selected item depends on.\n\nThe Experience page has the same **Filter by category** control on its site tree. Because the tree\nonly loads a branch's children when you expand it, picking a category automatically expands every\nancestor branch needed to reach each matching page, highlights the matches, and dims everything\nelse that's visible without hiding it — so you can still see where a match sits relative to the\nrest of the site. Clearing the filter leaves the tree as you left it.\n\n## Filtering which Contract you pick\n\nWhen adding new content from an Experience page's payload editor — \"New Component\" or \"Create\ninline\" — the Contract picker offers a **Filter by category** button. Pick a category and the\nchoices narrow to Contracts tagged with it; **Clear** brings back the full list. This is a\nconvenience for a large Contract library — it defaults to showing every eligible Contract, and you\ncan always clear the filter to reach one that isn't tagged.\n\n## Using a Category field on a Contract\n\nWhen building a Contract, add a field with type **Category**. In its settings, you can restrict\nwhich CategoryGroup(s) the field accepts — leave it empty to allow any group. In the Component\neditor, that field shows a **Choose…** button opening the same category picker; the chosen\ncategory displays as its full path (e.g. `topics/tech/ai`).\n\n## What happens when you rename or move a category\n\nRenaming a category, or moving it to a different parent, updates everywhere it's referenced\nimmediately — in every environment and app, no republishing needed. What *does* require\nrepublishing is a **tag added after publish**: a Component's set of published categories is frozen\nat publish time, exactly like its content. If you tag something new and want that reflected in\ndelivered results, publish it again.\n\n## Promotion and inheritance\n\nThe vocabulary exists in every environment already, so promoting tagged content never copies\ncategories. What rides along is the **group's presence**: promoting something tagged with a group\nnot yet added to the target adds it there (with its metadata Contract, if any), so the tags still\nvalidate. Environment inheritance works the same way — a child environment inherits which groups its\nparent has added, and their metadata, as read-only.\n\n## External taxonomy\n\nIf your organization has registered a content provider that also supplies taxonomy, its groups and\ncategories appear in the picker and the Taxonomy page alongside your own — marked **synced** and\nread-only. They belong to the environment the provider is registered in rather than to the\norganization vocabulary, and work identically to your own categories everywhere except editing:\nyou can tag content with them and use them in Category fields, but changing them happens on the\nprovider's own side, refreshed the same way its other content is.\n"
     },
     {
         "slug": "content-workflow",

package/dist/resources/helpCorpus.generated.js.map

@@ -1 +1 @@
-{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,knWAAknW;KAC3nW;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,gxdAAgxd;KACzxd;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,ggnBAAggnB;KACzgnB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,qyfAAqyf;KAC9yf;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,s3qBAAs3qB;KAC/3qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,6/HAA6/H;KACtgI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,wvJAAwvJ;KACjwJ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,82WAA82W;KACv3W;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,q+fAAq+f;KAC9+f;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u/JAAu/J;KAChgK;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,ugNAAugN;KAChhN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,w/OAAw/O;KACjgP;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,2hVAA2hV;KACpiV;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,8vKAA8vK;KACvwK;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,6hJAA6hJ;KACtiJ;CACF,CAAA"}
+{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,knWAAknW;KAC3nW;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,gxdAAgxd;KACzxd;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,ggnBAAggnB;KACzgnB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,qyfAAqyf;KAC9yf;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,s3qBAAs3qB;KAC/3qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,+mKAA+mK;KACxnK;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,o7PAAo7P;KAC77P;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,82WAA82W;KACv3W;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,q+fAAq+f;KAC9+f;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u/JAAu/J;KAChgK;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,ugNAAugN;KAChhN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,w/OAAw/O;KACjgP;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,2hVAA2hV;KACpiV;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,8vKAA8vK;KACvwK;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,6hJAA6hJ;KACtiJ;CACF,CAAA"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ebitex/content-mcp",
-  "version": "0.5.137",
+  "version": "0.5.140",
   "description": "An MCP server for ebitex Content: build and publish a content model from an AI agent.",
   "license": "Apache-2.0",
   "homepage": "https://developers.ebitex.io/getting-started/content-as-code/",