Skip to main content
Glama

Entyrax

by com.entyrax
OverviewDiscussionsAdmin

Server Details

PC hardware decision engine for Brazil (pt-BR): compatibility, GPU recommendations, build analysis.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct aspect: full build analysis, pairwise compatibility, and GPU recommendation. No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (analyze_build, check_compatibility, recommend_gpu_by_context), making the set predictable.

Tool Count4/5

Three tools is a reasonable size for a focused PC building assistant, covering the core decision points without overcomplicating.

Completeness3/5

The set covers full build analysis and compatibility but lacks recommendations for other individual components (e.g., CPU, motherboard) and price tracking, leaving some gaps.

Available Tools

3 tools
analyze_buildAnalisar build completoA
Read-onlyIdempotent
Inspect

Analisa um build CPU+Mobo+GPU. Retorna overall_quality, reasoning (why_this_mobo/why_this_gpu/budget_note), PSU recomendada e preços.

ParametersJSON Schema
NameRequiredDescriptionDefault
cpu_slugYesSlug da CPU (ex: ryzen-7-7800x3d)
gpu_slugYesSlug da GPU (ex: geforce-rtx-5070-ti)
mobo_slugYesSlug da placa-mãe (ex: gigabyte-b650-aorus-pro-ax)

Output Schema

ParametersJSON Schema
NameRequiredDescription
psuNoPSU recomendada para o conjunto
reasoningNowhy_this_mobo, why_this_gpu, budget_note
overall_qualityNoQualidade geral do build (ex: excellent, unbalanced)

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive. The description adds value by listing return fields (overall_quality, reasoning, PSU, prices) and confirms the tool's scope, which is consistent with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words, front-loaded with the core purpose. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of annotations and full output schema, the description sufficiently covers the tool's purpose and outputs. Missing error handling or prerequisites, but not critical for this straightforward tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description reinforces that these three slugs form a build and explains what the analysis returns, but does not add new details beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it analyzes a full CPU+Mobo+GPU build and returns specific outputs (overall quality, reasoning, PSU, prices). It distinguishes well from siblings like check_compatibility and recommend_gpu_by_context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for analyzing a complete build but does not explicitly state when to use it vs. siblings or provide when-not scenarios. Sibling tools are listed but no comparison is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_compatibilityVerificar compatibilidadeA
Read-onlyIdempotent
Inspect

Verifica compatibilidade e qualidade de pairing entre dois componentes (CPU+Mobo, CPU+GPU, GPU+Monitor). Retorna compatibility_status, pairing_quality, confidence e reasoning.

ParametersJSON Schema
NameRequiredDescriptionDefault
entity_aYesSlug do primeiro componente (ex: ryzen-7-7800x3d)
entity_bYesSlug do segundo componente (ex: gigabyte-b650-aorus-pro-ax)
pair_typeNoTipo do par. Opcional; se omitido, tenta os três.

Output Schema

ParametersJSON Schema
NameRequiredDescription
reasonNoJustificativa em pt-BR
pair_typeNocpu_mobo | cpu_gpu | gpu_monitor
compatibleNoSe o par funciona junto
confidenceNo0.0–1.0
pairing_qualityNoEx: excellent, balanced, bottleneck_risk
compatibility_statusNoEx: native_supported, needs_bios_update

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that when pair_type is omitted, the tool tries all three pair types, and explicitly lists return fields. This provides useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first covers purpose and components, second lists return fields. Every word earns its place; no fluff. Front-loaded with the core function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 params, output schema, annotations covering safety), the description is complete enough: it explains what pairs are checked, return fields, and behavior when pair_type is omitted. Missing details on error handling or quality metrics are acceptable given output schema presence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description repeats that entity_a and entity_b are slugs and mentions pair types, but does not add significant new meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks compatibility and pairing quality between two components, listing specific pair types (CPU+Mobo, CPU+GPU, GPU+Monitor) and return fields. This distinguishes it from siblings (analyze_build, recommend_gpu_by_context) which focus on full builds or recommendations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking specific component pairs, but does not explicitly contrast with sibling tools or mention when not to use it. The context is clear, but no exclusions or alternatives are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recommend_gpu_by_contextRecomendar GPU por contextoA
Read-onlyIdempotent
Inspect

Recomenda top GPUs dado contexto: resolução (1080p/1440p/4k), uso (gaming-aaa/gaming-competitive/produtividade) e orçamento em BRL.

ParametersJSON Schema
NameRequiredDescriptionDefault
use_caseYesUso principal da máquina
budget_brlYesOrçamento máximo em BRL (ex: 3500)
resolutionYesResolução alvo do monitor

Output Schema

ParametersJSON Schema
NameRequiredDescription
picksNoGPUs recomendadas em ordem de adequação
reasoningNoResumo do porquê do ranking

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety and idempotency. Description adds no additional behavioral traits beyond stating it recommends GPUs. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundant information, front-loaded with key action and context. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists (not shown but signaled), description adequately covers the tool's purpose with three parameters. No missing context for a recommendation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value by providing examples (e.g., '1080p/1440p/4k', 'gaming-aaa/gaming-competitive/produtividade') and clarifying budget format ('em BRL'), which aids the agent in parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb ('Recomenda'), resource ('top GPUs'), and context parameters (resolution, use case, budget). Distinguishes from sibling tools (analyze_build, check_compatibility) by focusing on GPU recommendation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage when needing GPU recommendations given context, but provides no explicit guidance on when to use versus alternatives or exclusions. Siblings exist but no differentiation stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updates
    • Changedanalyze_build4 fields changed
      • addedInput schema / properties / cpu_slug / description
        Added value: +"Slug da CPU (ex: ryzen-7-7800x3d)"
      • addedInput schema / properties / gpu_slug / description
        Added value: +"Slug da GPU (ex: geforce-rtx-5070-ti)"
      • addedInput schema / properties / mobo_slug / description
        Added value: +"Slug da placa-mãe (ex: gigabyte-b650-aorus-pro-ax)"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "description": "Análise do build com veredicto e PSU recomendada.",
+  "properties": {
+    "overall_quality": {
+      "description": "Qualidade geral do build (ex: excellent, unbalanced)",
+      "type": "string"
+    },
+    "psu": {
+      "description": "PSU recomendada para o conjunto",
+      "type": "object"
+    },
+    "reasoning": {
+      "description": "why_this_mobo, why_this_gpu, budget_note",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
    • Changedcheck_compatibility2 fields changed
      • changedInput schema / properties / pair_type / description
        Previous value: -"Opcional; se omitido, tenta os três."New value: +"Tipo do par. Opcional; se omitido, tenta os três."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "description": "Veredicto de compatibilidade com reasoning.",
+  "properties": {
+    "compatibility_status": {
+      "description": "Ex: native_supported, needs_bios_update",
+      "type": "string"
+    },
+    "compatible": {
+      "description": "Se o par funciona junto",
+      "type": "boolean"
+    },
+    "confidence": {
+      "description": "0.0–1.0",
+      "type": "number"
+    },
+    "pair_type": {
+      "description": "cpu_mobo | cpu_gpu | gpu_monitor",
+      "type": "string"
+    },
+    "pairing_quality": {
+      "description": "Ex: excellent, balanced, bottleneck_risk",
+      "type": "string"
+    },
+    "reason": {
+      "description": "Justificativa em pt-BR",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
    • Changedrecommend_gpu_by_context4 fields changed
      • changedInput schema / properties / budget_brl / description
        Previous value: -"Orçamento máximo em BRL"New value: +"Orçamento máximo em BRL (ex: 3500)"
      • addedInput schema / properties / resolution / description
        Added value: +"Resolução alvo do monitor"
      • addedInput schema / properties / use_case / description
        Added value: +"Uso principal da máquina"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "description": "Ranking de GPUs para o contexto, com reasoning.",
+  "properties": {
+    "picks": {
+      "description": "GPUs recomendadas em ordem de adequação",
+      "items": {
+        "properties": {
+          "avg_fps": {
+            "description": "FPS médio estimado no contexto",
+            "type": "number"
+          },
+          "avg_price_brl": {
+            "description": "Preço médio em BRL",
+            "type": "number"
+          },
+          "name": {
+            "description": "Nome da GPU",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "reasoning": {
+      "description": "Resumo do porquê do ranking",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  2. 3 tool updates
    • First observedanalyze_build
    • First observedcheck_compatibility
    • First observedrecommend_gpu_by_context

Related MCP Connectors

Related MCP Servers

  • PC Build Advisor MCP

    finnestprogrammer111
    A
    license
    Not graded
    quality
    C
    maintenance
    Checks PC component compatibility and estimates power supply requirements from user-supplied specifications, returning structured conflicts, fixes, and recommended PSU capacity.
    MIT

  • kr-pc-deals-mcp

    edward-kim-dev
    A
    license
    B
    quality
    D
    maintenance
    Enables AI assistants to search and compare Korean PC parts prices from Danawa and Compuzone, build assembly estimates with automatic compatibility checks, and track price history.
    11
    7 npm
    11
    MIT

  • boot-doctor-mcp

    pamela-0
    A
    license
    A
    quality
    C
    maintenance
    Provides deterministic PC no-boot/no-display troubleshooting with ranked repair steps and real, sourced BIOS beep-code lookup tables. Enables users to diagnose hardware issues without LLM guesswork.
    2
    1
    MIT
  • Yamaru Hardware Probe by yamaru-eu

    Yamaru Hardware Probeofficial

    yamaru-eu
    A
    license
    A
    quality
    D
    maintenance
    Expert system hardware probe and performance diagnostic engine for AI, Gaming, and High-Performance workflows. Provides deep system insights such as real-time monitoring, thermal diagnostics, and LLM optimization.
    11
    28 npm
    7
    Apache 2.0
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources