Update to NeuronSearchLab

{
  "name": "neuronsearchlab",
  "description": "Manage and analyze an authenticated NeuronSearchLab customer workspace through the hosted NSL MCP. Use for recommendation contexts, pipelines, ranking rules, segments, experiments, training jobs, catalogue search, ranking explanations, analytics, event types, API-key inventory or revocation, and integrations. Do not use for credential creation, billing, arbitrary API calls, or resources outside the signed-in workspace.",
  "included_files": [],
  "skill_md_contents": "---\nname: neuronsearchlab\ndescription: Manage and analyze an authenticated NeuronSearchLab customer workspace through the hosted NSL MCP. Use for recommendation contexts, pipelines, ranking rules, segments, experiments, training jobs, catalogue search, ranking explanations, analytics, event types, API-key inventory or revocation, and integrations. Do not use for credential creation, billing, arbitrary API calls, or resources outside the signed-in workspace.\n---\n\n# NeuronSearchLab\n\nUse the NeuronSearchLab MCP tools associated with this plugin. Operate only in the workspace authorized by the signed-in user.\n\nIf the tools require authentication, ask the user to connect or sign in to NeuronSearchLab. Never ask the user to paste an API key, bearer token, OAuth code, or other secret into the conversation.\n\n## Information boundaries\n\nReturn customer-visible workspace information when it is relevant to the request, including resource IDs and names, configuration, status, catalogue metadata, ranking explanations, and aggregated analytics.\n\nDo not expose:\n\n- Secret values, bearer tokens, OAuth codes, or unmasked credentials.\n- Hidden server configuration, raw internal error traces, or infrastructure details.\n- Data belonging to another customer or workspace.\n- Unnecessary personal data or identifiers unrelated to the request.\n\nIf a result unexpectedly contains a secret-like value, redact it and summarize the safe fields.\n\n## Workflow\n\n1. Identify the requested workspace resource, context, pipeline, item, user, segment, experiment, or time range. Ask a concise clarification only when the target or intended change is ambiguous.\n2. Inspect current state with list or get tools before making a recommendation or change.\n3. Prefer the most specific first-class tool for the task.\n4. Make changes only when the user explicitly asks for them. Verify the exact resource ID and current state first.\n5. Re-read the resource after a successful change when a read tool is available, then summarize what changed.\n\n## Tool selection\n\n- Contexts: `list_contexts`, `get_context`, `create_context`, `update_context`.\n- Pipelines: `list_pipelines`, `get_pipeline`, `create_pipeline`, `update_pipeline`, `clone_pipeline`, `activate_pipeline`, `deactivate_pipeline`, `delete_pipeline`.\n- Ranking rules: `list_rules`, `get_rule`, `create_rule`, `update_rule`, `enable_rule`, `disable_rule`, `toggle_rule`, `delete_rule`.\n- Segments: `list_segments`, `get_segment`, `create_segment`, `update_segment`, `delete_segment`.\n- Experiments: `list_experiments`, `get_experiment`, `get_experiment_results`, `refresh_experiment_results`, `create_experiment`, `update_experiment`, `start_experiment`, `stop_experiment`.\n- Training: `list_training_jobs`, `get_training_job`, `create_training_job`, `cancel_training_job`.\n- Catalogue and ranking: `search_items`, `explain_ranking`.\n- Analytics: `get_ranking_metrics`, `get_user_analytics`, `get_item_analytics`, `compare_items`, `top_items`.\n- Administration: `list_event_types`, `create_event_type`, `update_event_type`, `delete_event_type`, `list_api_keys`, `revoke_api_key`, `list_integrations`.\n\nDo not invent unavailable tools or use an arbitrary HTTP or platform-API fallback.\n\n## Common workflows\n\n### Diagnose a ranking\n\n1. Use `search_items` when an item ID is not known.\n2. Use `explain_ranking` for the identified user, item, and context.\n3. Add relevant ranking, user, or item analytics when the user asks for performance context.\n4. Explain the observed signals before suggesting configuration changes. Do not change rules or pipelines unless explicitly requested.\n\n### Configure recommendations\n\n1. List and inspect the target context, pipeline, rule, or segment.\n2. Describe the proposed change and its scope when the effect is not obvious.\n3. Apply only the requested fields. Preserve unrelated configuration.\n4. Re-read and report the resulting state.\n\n### Review experiments or training\n\nUse stored experiment results by default. Call `refresh_experiment_results` only when the user asks for fresh results. Inspect an experiment or training job before starting, stopping, updating, or cancelling it.\n\n### Work with API keys\n\nShow only masked key metadata returned by `list_api_keys`. The hosted plugin cannot create or reveal secret-bearing credentials. Revoke a key only when the user clearly identifies the intended key.\n\n## Change safety\n\nTreat pipeline activation or deactivation, rule changes, experiment start or stop, training-job creation or cancellation, event-type changes, and API-key revocation as high-impact operations.\n\nFor delete, revoke, stop, cancel, or other irreversible operations, confirm the exact resource and scope unless the user has already specified them unambiguously. Never broaden a mutation from one resource to multiple resources without explicit instruction.\n\n## Response style\n\nLead with the result. Include the customer-visible names and IDs needed to verify it, the relevant status or time range, and any assumptions. Explain that recommendation and ranking outputs are probabilistic when that affects interpretation.\n"
}