Provides tools for predicting LLM performance and optimizing local LLM inference using Ollama, including checking compatibility of specific models and getting recommendations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Yamaru Hardware Probe Analyze my system performance"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Expert system hardware probe and performance diagnostic engine for AI, Gaming, and High-Performance workflows. This is a Model Context Protocol (MCP) server that provides deep system insights beyond simple specifications.
🔍 Deep Hardware Inventory: Comprehensive analysis of CPU, RAM, GPU (VRAM/Bandwidth), Storage, and OS topology.
⚡ Real-time Performance Monitoring: Live tracking of system load and identification of resource-hogging processes.
🧊 Thermal & Power Diagnostics: Detects thermal throttling and frequency clipping to resolve unexpected slowness.
🤖 AI/LLM Optimization: Specialized tools for predicting LLM performance, calculating quantization fit, and optimizing runtimes (Ollama, CUDA, Metal).
🛡️ Privacy-First: Automatic anonymization of unique hardware identifiers before any remote transmission.
Related MCP server: MCP System Monitor Server
gemini extension install @yamaru-eu/hardware-probeAdd this to your MCP settings file (e.g., npx-config.json or claude_desktop_config.json):
{
"mcpServers": {
"yamaru-probe": {
"command": "npx",
"args": ["-y", "@yamaru-eu/hardware-probe"]
}
}
}analyze_local_system: Full hardware inventory.
analyze_performance: Real-time performance metrics and top processes.
analyze_ram_pressure: Detailed memory pressure and RSS analysis for deep RAM troubleshooting.
check_storage_health: Disk SMART health, firmware, and I/O bottleneck analysis.
thermal_profile: Real-time CPU/GPU thermal states, fan speeds, and frequency throttling detection.
diagnose_antivirus_impact: Detects EDR/Antivirus conflicts and exclusion coverage on dev paths.
monitor_system_health: Statistical health report (CPU load, RAM usage, temperature) with min/max/avg over a configurable time window (up to 10 minutes).
check_llm_compatibility (BETA): Predicts performance for a specific LLM model via remote API.
get_llm_recommendations (BETA): Recommends the best local models via remote API.
analyze_inference_config: Deep-dive into AI runtimes and environment variables.
When used with Gemini CLI, this extension provides the following expert skills:
hardware-performance-expert: Global protocol for system health and troubleshooting.
local-inference-optimizer: Specialized logic for fine-tuning local LLM runs.
npm install # Install dependencies
npm run build # Compile TypeScript → dist/
npm run test # Run test suite
npm run inspector # Test tools in the MCP InspectorApache 2.0 - Part of the Yamaru Project.
Performs a deep scan for LLM inference optimization: GPU details, real memory bandwidth benchmark, ML runtimes (Ollama, Docker, WSL), and environment variables.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether the scan modifies system state, required permissions, or resource impact. It only lists what it scans, leaving the agent to infer that it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the core purpose, then enumerates scan areas efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool scans but does not explain return values or output format. Since no output schema exists, the agent might need guidance on what to expect from the scan result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters. Baseline score 4 as per rules. The description does not need to add parameter meaning since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a deep scan for LLM inference optimization, listing specific areas: GPU details, memory bandwidth, ML runtimes, and environment variables. It distinguishes from sibling tools like analyze_local_system by focusing on inference optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for LLM inference optimization but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives among siblings or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the hardware specifications of the local machine: CPU, RAM, motherboard and OS. Returns a structured JSON object.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool reads (non-destructive) and returns a JSON object, which covers core behavior. However, it does not mention potential performance impact or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the core purpose and return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks an output schema. The description says 'structured JSON object' but does not specify exact fields or format, leaving ambiguity for the agent. Additional detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100% (trivially). The description adds meaning by explaining what the tool returns, meeting the baseline for no-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads hardware specifications (CPU, RAM, motherboard, OS) and returns a structured JSON. This distinguishes it from sibling tools like 'analyze_ram_pressure' which focuses on RAM specifics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving hardware specs but does not provide explicit guidance on when to use versus siblings or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provides real-time system performance: CPU load, memory usage, and top processes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only mentions 'real-time' but omits whether it's read-only, safe to call repeatedly, or requires any permissions. Minimal behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with key information. Efficient, though slightly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at return format. It says 'provides' but not how the data is structured (e.g., JSON object). Adequate for a simple snapshot tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined, so baseline is 4. The description adds no parameter-specific meaning because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides real-time system performance metrics (CPU load, memory usage, top processes), which is specific. However, it does not distinguish from siblings like 'monitor_system_health' or 'analyze_ram_pressure', which may overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It only describes what it does, without context about prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports current memory pressure: total/used/free/available memory, swap usage, and top processes by RSS.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly implies a read-only diagnostic operation, but does not explicitly state non-destructiveness or any other behavioral traits such as permissions or impact. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's function without extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the essential inputs (none) and outputs (memory pressure metrics). It does not specify return format or interpretation, but for a simple diagnostic tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100%. According to guidelines, baseline is 4. The description appropriately adds no redundant parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reports' and the resource 'current memory pressure' with specific metrics (total/used/free/available memory, swap usage, top processes by RSS), making the tool's purpose unmistakable and distinguishing it from sibling tools that focus on storage, thermal, or other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like monitor_system_health or analyze_local_system. Context is implied by the specific metrics, but exclusions or selection criteria are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(BETA) Checks if a specific LLM model can run on this machine. Returns optimal quantization and estimated tokens per second. Requires remote API connection.
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | Yes | LLM model name (e.g., 'Llama 3.1 70B') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states returns and a requirement (remote API) but does not disclose failure modes, permissions, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the purpose, return values, and a key requirement. No wasted words, front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the main function and a critical requirement. It could mention error handling or connection failures, but overall it is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter model_name is fully described in the input schema with an example. The description adds no extra meaning beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a specific LLM model can run on this machine, returns optimal quantization and estimated tokens per second, and distinguishes from siblings like get_llm_recommendations by focusing on feasibility of a given model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (requires remote API connection) but does not explicitly state when to use this tool versus alternatives (e.g., get_llm_recommendations) or when not to use it. Guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports per-disk health: type (NVMe/SSD/HDD), vendor, temperature, SMART status, and firmware.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Reports' which implies a read-only operation, but does not disclose behavioral traits such as required permissions, system impact, data freshness, or whether the tool queries live data or cached results. The description lacks sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It efficiently conveys the purpose and output, placing key information upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is mostly complete, listing the reported attributes. However, it does not specify the structure (e.g., array of objects, per-disk listing) or whether a summary health status is included. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so there is no parameter documentation needed. The description adds value by detailing the output fields (type, vendor, temperature, SMART status, firmware), which is beyond the empty schema. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Reports' and the resource 'per-disk health', listing specific fields (type, vendor, temperature, SMART status, firmware). This distinguishes it from sibling tools like thermal_profile (temperature focus) and monitor_system_health (broader health).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving detailed disk health information but does not provide explicit guidance on when to use it versus alternatives like monitor_system_health or thermal_profile. No when-not-to-use or alternative names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detects running antivirus/EDR products and reads their exclusion rules. Checks dev hot paths coverage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states detection and reading actions (non-destructive) but does not detail potential side effects, required privileges, or operational impact beyond the stated actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise front-loaded sentences with no redundant information. Every sentence adds value and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is moderately complete: it explains the tool's actions but lacks return value details. Since there is no output schema, the description should inform about output format or content, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0 parameters with 100% coverage. Since no parameters exist, the baseline is 4. The description adds no parameter details, which is acceptable as there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it detects running antivirus/EDR products, reads exclusion rules, and checks dev hot paths coverage. This is a specific verb+resource description that distinguishes it from sibling tools focusing on other system aspects like RAM, storage, or thermal analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for antivirus impact analysis but does not explicitly state when to use versus alternatives. No scenarios or exclusions are mentioned, providing only implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the expert instructions and rules for optimizing LLM inference on this specific hardware. Call this to learn HOW to interpret analyze_inference_config results.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It describes the return type but does not disclose behavioral traits such as idempotency, side effects, or whether it is read-only. For a knowledge retrieval tool, this is a minor gap, but still lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential and front-loaded. The first sentence states the core function, the second adds usage context. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the main purpose and usage. It could mention any prerequisites or safety notes, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (vacuously). The description adds meaning by explaining the output context, exceeding the baseline expectation for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Returns' specifies the action and resource: expert instructions/rules for optimizing LLM inference. It explicitly states the tool's role in interpreting analyze_inference_config results, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit guidance: 'Call this to learn HOW to interpret analyze_inference_config results.' This implies a specific use case and sequence, though it does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(BETA) Recommends the best LLM models that can run locally on this machine. Requires remote API connection.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max recommendations | |
| use_case | No | Use case |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions BETA status and remote API requirement, but omits critical traits such as error behavior, latency, network dependency, output format, or what happens if no models are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with parenthetical note. Very concise with no filler, though could benefit from slightly more detail to be fully self-contained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is incomplete. It lacks information about return values, error conditions, rate limits, or how the remote API connection is used. Param coverage is high but overall completeness is low for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (limit, use_case) described. Description adds no extra meaning beyond schema definitions, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Recommends the best LLM models that can run locally on this machine.' It includes a clear verb (recommends) and resource (LLM models), and distinguishes from sibling tools like check_llm_compatibility or analyze_inference_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives context ('requires remote API connection') but no explicit guidance on when to use versus alternatives. It implies usage when seeking local model recommendations, but does not state when not to use or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitors system metrics (CPU load, RAM usage, CPU temperature) over a configurable duration (up to 10 minutes) and returns min/max/avg statistics. Use duration_seconds to set the observation window and interval_seconds to control sampling granularity.
| Name | Required | Description | Default |
|---|---|---|---|
| duration_seconds | No | Monitoring duration in seconds (1-600) | |
| interval_seconds | No | Sampling interval in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that monitoring is over a configurable duration up to 10 minutes and returns statistics, but does not disclose whether it is read-only or any potential resource impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the core function and the second explains the parameters. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions returning min/max/avg statistics but does not specify the structure per metric or any prerequisites. Slightly incomplete but sufficient for a simple monitoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: duration_seconds sets the observation window and interval_seconds controls sampling granularity, going beyond the basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it monitors system metrics (CPU load, RAM usage, CPU temperature) over a configurable duration and returns min/max/avg statistics. This distinguishes it from sibling tools like analyze_ram_pressure or check_storage_health that focus on specific subsystems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as analyze_ram_pressure or thermal_profile. The description lacks context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports current CPU and GPU thermal and frequency state: temperature, utilization, and fan speed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly indicates a non-destructive read operation reporting current state, but lacks additional behavioral context such as permissions, rate limits, or what happens if sensors are unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and includes key metrics. Every word earns its place with no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description adequately covers the return concept (temperature, utilization, fan speed). However, it could specify units or data types for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. According to guidelines, baseline is 4. The description adds context about what the tool reports, though no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports CPU and GPU thermal and frequency state, including temperature, utilization, and fan speed. It distinguishes from sibling tools like monitor_system_health by focusing specifically on thermal and frequency metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking thermal state but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.3analyze_inference_configanalyze_local_systemanalyze_performanceanalyze_ram_pressurecheck_llm_compatibilitycheck_storage_healthdiagnose_antivirus_impactget_inference_expert_knowledgeget_llm_recommendationsmonitor_system_healththermal_profileSeveral tools overlap in purpose: analyze_ram_pressure, analyze_performance, and monitor_system_health all deal with CPU/memory metrics, causing potential confusion. Additionally, system specs are split across analyze_local_system and analyze_inference_config, adding ambiguity.
Tool names mostly follow a verb_noun pattern but use a mix of verbs (analyze, check, get, diagnose, monitor) without uniform style. Some compound nouns are inconsistent in format, making the set moderately predictable.
With 11 tools, the count is well within the 3-15 optimal range. Each tool serves a distinct purpose related to hardware probing and LLM inference, without being excessive.
The set covers hardware specs, storage health, thermal, performance, and LLM inference utilities, but lacks basic metrics like disk usage and network info. The inclusion of antivirus impact is niche, while GPU info is only available in inference context.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Verified hardware specifications (GPU, CPU, PSU) for autonomous agents. No scraping needed.
CPU telemetry & benchmarking, SHA-256 hashing, AES-256-GCM storage, AI video/image via Nova.
GPU and LLM inference benchmarks, hardware evidence, deployment recommendations, and launch configs.
Run, build, and validate firmware on virtual hardware from your AI agent. Hardware knowledge corpus.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yamaru-eu/hardware-probe'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
