Servidor MCP de Orbilyn

• Nome no registrocom.orbilyn/mcpverificado no registro MCP

O nome no registro fica sob orbilyn.com. O registro só libera esse espaço de nomes para quem prova controle do domínio por DNS ou HTTP.

• Estadorespondeverificado em 2026-10-28
• Ferramentas21
• O servidor se chamaorbilyn
• Versão do servidor1.4.0
• Versão do protocolo2025-03-26

Em 2026-10-28 o servidor respondeu a initialize e tools/list sem login. Primeira resposta em 327 ms.

• Ainda não avaliamos se as ferramentas fazem o trabalho do produto.

Dito por regras a partir das medições acima. A primeira chamada provável é a escolha de um modelo na lista de ferramentas; leia a descrição antes de confiar nela.

• Nota INITE MCP73 de 100responde 96 · definições 77 · contexto 100 · conexão 100 · reduzida pelos sinais de alerta abaixo
• Respondeuem 100% dos dias7 de 7 verificações diárias
• Mediana da primeira resposta1377 ms
• Espaço no contexto do agente≈ 2.077 tokensas definições de todas as ferramentas (21), que o agente carrega a cada turno
• Definições das ferramentasB · 77 de 100
• Resultados tipados0 de 21 ferramentasdeclaram outputSchema: o resultado chega tipado e é lido de uma vez

• Parâmetros sem descrição: em 8 de 21
• Sem dizer se só lê ou se pode destruir: 21 de 21

Um programa verifica o servidor uma vez por dia: initialize e tools/list, sem modelo. Os tokens são o tamanho das definições, a cerca de quatro caracteres por token. A nota é a média de seis verificações do nome, da descrição, do esquema e das anotações de cada ferramenta; diz se as ferramentas estão bem descritas, não se funcionam. A nota pesa só o que foi medido: se responde (25%), se faz o trabalho do produto (25%), definições (20%), contexto (10%), uso (10%) e a facilidade de conectar (10%). Uma parte não medida fica de fora, e uma instrução oculta limita a nota a 40. O estado dos servidores MCP dos fornecedores: método e números →

• list_integrations

  List Orbilyn channel integrations (metadata only, no secrets).

• list_mismatches

  List mismatches from a comparison run (latest if runId omitted).

• get_monitoring_alerts

  Get unread Monitoring alerts (new mismatches from scheduled runs).

• find_product

  Find a product by SKU and/or EAN with stock and price per channel.

• get_comparison_summary

  Summaries of recent comparison / history runs (counts, labels).

• catalog_health_score

  Catalog health score 0–100 with breakdown: photos, descriptions, prices, stock, duplicates, channel_consistency. Uses the latest comparison run (or setId) plus Overview media signals. Example: {"setId":"<uuid>"}.

• list_critical_issues

  List CatalogIssue rows sorted by impact (severity then type). Default severity=critical. Supports limit + offset pagination. Example: {"limit":20,"offset":0,"severity":"critical"}. Issue shape: sku, channel, type, severity, current…

• prepare_fix_list

  Prepare a CatalogIssue fix list as JSON (default) or CSV. Same schema as list_critical_issues. Example JSON: {"format":"json","limit":50}. Example CSV: {"format":"csv","severity":"all"}.

• ai_readiness_report

  Shopping-agent readiness: catalog products agents would reject (missing GTIN/EAN, photos, description, attributes, price/stock) plus what to fill in. Shared CatalogIssue format. Every result includes rules_version, audit_date…

• explain_issue

  Per SKU: what shopping-agent readiness checks failed and why. Same meta envelope (rules_version, audit_date, checked_fields, profile) + CatalogIssue list + explanations. Example: {"sku":"SKU-100"}.

• get_webhook_config

  Read Scale webhook subscription (URL, enabled, event catalog). Signing: X-Orbilyn-Signature HMAC-SHA256. Webhook sample items use the CatalogIssue schema (sku + type preserved; additive fields).

• configure_webhook

  Configure outbound webhook URL/secret (requires write scope). Events: catalog.duplicate.new, catalog.drift.status, sync.failure, monitoring.*.

• run_monitoring

  Trigger a Monitoring compare run now (requires action scope).

• start_catalog_audit

  Start a catalog audit over persisted comparison/Overview data (no live re-import; safe for large catalogs). Returns auditId + status. Result uses shared CatalogIssue format. Webhook: audit.completed. Requires action scope.

• get_audit_status

  Poll async catalog audit status by auditId (pending|running|succeeded|failed).

• get_audit_result

  Fetch catalog audit result (CatalogIssue list + health). Paginate with limit/offset. Fails if audit is still pending/running.

• create_monitor

  Create a Scale Monitoring pair (Alerty/Automatyzacja). Params: sources, thresholds, issueTypes, actions (webhook|email|fix_list). Write scope.

• update_monitor

  Update an existing Monitoring pair (thresholds, sources, actions, enabled). Write scope.

• pause_monitor

  Pause (disable) a Monitoring pair. Write scope.

• list_monitors

  List Scale Monitoring pairs configured for this account.

• get_monitor_history

  Monitoring run history with deltas vs previous run (new / fixed / open) and CatalogIssue samples.