mcp-server-mcsa

by LGDiMaggio

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Every tool has a clearly distinct purpose. Spectrum-related tools are differentiated by method (FFT, Welch, envelope, STFT). Fault detection tools are separated by fault type (bearing, rotor bar, eccentricity, stator). Workflow tools like run_full_diagnosis and diagnose_from_file are distinct in input method. No ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., compute_spectrum, detect_broken_rotor_bars). The verbs are descriptive and uniform, making the set predictable and easy to navigate.
Tool Count4/5
With 21 tools, the set is slightly above the typical 3-15 range but still reasonable given the comprehensive domain coverage. Each tool serves a specific, necessary function in the MCSA pipeline, so the count feels appropriate rather than bloated.
Completeness5/5
The tool set covers the entire MCSA workflow: file inspection, loading, preprocessing, multiple spectrum computation methods, fault-specific detection, and automated full-diagnosis pipelines. Utilities for data management (list/clear stored data) and test signal generation are included, leaving no obvious gaps.
Average 3.9/5 across 21 of 21 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on February 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, has side effects, requires authorization, or modifies state. For a computation tool, one might assume it's safe, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs: one for purpose, one for context. No wasted words, front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and an output schema (though not shown), the description covers the core idea but could be more explicit about how the energy is computed (e.g., integrates the PSD). It assumes domain knowledge that may not be universal.
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 description coverage is 100%, establishing good baseline. The description adds value by recommending 'spectrum_id' over raw arrays and specifying the bandwidth default. This enhances the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes integrated spectral energy in a frequency band, and mentions its use as a fault/cavitation indicator. However, it does not explicitly distinguish from sibling tools like compute_power_spectral_density or compute_spectrum.
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?
It's described as useful for fault/cavitation indication, but no explicit guidance on when to use this tool vs alternatives (e.g., find_spectrum_peaks, detect_bearing_faults). No exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses the method (Welch's), the return of a spectrum_id and compact summary, but does not mention read-only nature, side effects, or prerequisites. The description adds some context but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with key information. No wasted words. Could potentially add a bit more detail without becoming verbose, but currently it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description is adequate but not thorough. It mentions the primary output but does not elaborate on the 'compact summary' or provide additional context for parameter choices. With moderate complexity, a bit more detail would improve completeness.
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%, so baseline is 3. The description does not add any additional parameter semantics; it merely repeats the tool's purpose. The schema already documents each parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes PSD using Welch's method, and mentions it's better for noisy signals and trend analysis than a raw FFT. However, it does not differentiate well from sibling tools like compute_spectrum or compute_envelope_spectrum, which may also be used for spectral analysis.
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?
Provides a usage hint (better for noisy signals/trend analysis) but does not explicitly state when to use this tool versus alternatives among siblings, nor when not to use it. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains the underlying theory (sidebands due to stator asymmetry) but does not disclose behavioral traits such as whether it modifies stored data, required permissions, or computational cost. A score of 3 is appropriate given the lack of annotations and minimal side-effect disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences covering purpose and theory. It is front-loaded and contains no fluff. A slight deduction for lacking structure (e.g., bullet points or clear sections) but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and existence of an output schema (not shown but indicated), the description is moderately complete. It explains the fault detection principle but omits details about the output format, error conditions, or prerequisite steps (e.g., spectra must already be computed).
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 the baseline is 3. The description adds no additional meaning beyond the schema; it mentions 'current spectrum' but does not elaborate on parameter usage or formats. No enhancement.
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 detects stator inter-turn short circuit faults from current spectrum, specifying the sideband frequencies (f_s ± 2k·f_r). This verb-resource pair is specific and distinguishes it from sibling tools like detect_bearing_faults or detect_eccentricity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., detect_bearing_faults, diagnose_from_file). There is no mention of prerequisites, context, or scenarios where it is appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions returning a spectrum_id and compact summary but does not disclose whether the signal is stored permanently, computational cost, side effects, or safety (e.g., idempotent). Minimal behavioral context beyond what schema implies.
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?
Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic purpose and output usage but lacks guidance on when to choose this over similar sibling tools (e.g., compute_power_spectral_density) and what 'compact summary' contains. Adequate but gaps remain.
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%, so baseline is 3. The description adds 'preferred over raw array' for signal_id, which adds value, but otherwise does not explain parameter meaning beyond schema descriptions.
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 computes the single-sided amplitude spectrum (FFT) of a current signal, specifying the output (spectrum_id and top peaks summary). It distinguishes from siblings by focusing on current signal amplitude spectrum and downstream fault-detection use.
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 use for fault detection ('Use spectrum_id in downstream fault-detection tools') and recommends signal_id over raw array, but does not explicitly contrast with sibling tools like compute_envelope_spectrum or compute_power_spectral_density.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states it computes a fault index and returns a classification, but does not specify whether the tool is read-only, modifies stored data, or has any side effects. Since it accepts spectrum IDs or raw arrays but does not clarify that it does not alter them, transparency is lacking.
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?
Two concise sentences: first states purpose, second explains computation and output. No unnecessary words, front-loaded with key action, and efficient for agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 0 required, and presence of output schema, the description adequately covers the core functionality. However, it lacks context about typical usage flow (e.g., needing a spectrum from compute_spectrum), relationship to sibling tools, and what the output schema contains. Could be more complete for an agent new to the domain.
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%, so baseline is 3. The description adds algorithmic context (sideband calculation, relative to fundamental) that helps interpret the roles of supply_freq, poles, rotor_speed_rpm, and tolerance_hz, improving parameter understanding beyond schema descriptions.
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 detects broken rotor bar faults from current spectrum, specifies the computational method using sidebands at (1 ± 2s)·f_s, and lists the severity classifications. This distinguishes it from sibling fault detection tools like detect_bearing_faults or detect_stator_faults.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 detect_bearing_faults or run_full_diagnosis. The description does not mention prerequisites, required data sources, or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses a limitation (weak signatures) but lacks details on return values, side effects, or detection confidence.
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 concise with three sentences, front-loaded with the purpose, and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameter descriptions are complete, the description is adequate but lacks details on detection criteria or required inputs beyond spectrum_id.
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%, so the baseline is 3; the description adds no additional meaning beyond the physical mechanism, which is already implied by the context.
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 detects bearing defect signatures in the stator-current spectrum, distinguishing it from siblings like detect_broken_rotor_bars or compute_bearing_frequencies.
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 notes that bearing signatures are weak and suggests envelope analysis or vibration, implying when the tool might be limited, but does not explicitly specify when to use this tool over other detect_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Only states calculation purpose; does not disclose any behavioral traits (e.g., side effects, permission needs, accuracy limits). Minimal transparency beyond function.
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?
Two sentences, front-loaded with purpose, followed by output context. No extraneous words; efficient and structured.
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?
Adequately describes inputs and outputs for a calculation tool. Could mention that poles must be even or that rotor speed should be below synchronous speed, but not essential 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 covers parameters with descriptions (100% coverage). The description does not add meaning beyond the schema; baseline 3 is appropriate.
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?
Clearly states it calculates motor operating parameters from nameplate and measured data, listing specific outputs (synchronous speed, slip, rotor frequency, slip frequency). Distinguishes from sibling tools like compute_bearing_frequencies by noting outputs are prerequisites for fault frequency calculations.
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?
Implicitly conveys usage: when motor parameters are needed for fault frequency calculations. Does not explicitly state when not to use or provide alternatives, but the context with sibling tools clarifies its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It explains normalised vs absolute frequencies and sidebands, but does not disclose any potential limitations, prerequisites (e.g., bearing geometry knowledge), or side effects. It is adequate but not comprehensive.
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?
Three concise sentences front-load the purpose and list outputs. Every sentence adds value with no redundancy.
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 existence of an output schema (not shown) and the complexity of bearing frequencies, the description adequately covers inputs, outputs, and conditional behavior. It is nearly complete for an agent to invoke correctly.
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 tool description adds context (e.g., 'multiples of shaft speed') but does not significantly enhance meaning beyond the schema. Baseline 3 is appropriate.
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 uses a specific verb 'Calculate' followed by well-known bearing fault frequencies (BPFO, BPFI, BSF, FTF), clearly distinguishing it from sibling tools like 'compute_fault_frequencies' (which is general) and 'detect_bearing_faults' (detection vs calculation).
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 use for computing bearing frequencies, but does not explicitly state when to use this tool over siblings like 'compute_fault_frequencies' or 'detect_bearing_faults'. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions analyzing sidebands and returning severity classification, but lacks details on assumptions (e.g., steady-state operation), limitations, or behavior with incomplete inputs. The description adds the sideband formula but remains somewhat opaque about the underlying algorithm.
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 short paragraphs with no redundant words. The primary action (detect eccentricity) is front-loaded, and the key technical detail (sideband formula) is included efficiently.
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 8 parameters (all with defaults) and an output schema (context confirms exists), the description covers the high-level process and key formula. It could mention typical output structure or severity levels, but the output schema likely provides that. Adequate for a specialized analytical 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%, so the baseline is 3. The description adds the sideband formula context but does not significantly extend the meaning of individual parameters beyond what the schema already describes. No extra clarity on parameter relationships or typical values.
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 detects air-gap eccentricity faults from current spectrum, specifies the analysis of sidebands at f_s ± k·f_r for static and dynamic eccentricity, and notes it returns severity classification. This distinguishes it from sibling tools like detect_bearing_faults or detect_broken_rotor_bars.
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 when a current spectrum is available and eccentricity detection is needed, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The context is clear but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool deletes from disk and memory, implying a destructive operation. With no annotations, it provides basic behavioral context but does not cover irreversibility or error handling. It is adequate but not extensive.
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 long with no fluff. It front-loads the action and immediately clarifies the parameter usage, making it highly efficient.
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?
For a simple deletion tool with one parameter, the description is complete. It covers both usage modes. The presence of an output schema means return values are handled elsewhere. It could mention confirmation or side effects, but it is sufficient.
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%, and the description's parameter explanation ('Pass a specific data_id to remove one item, or omit to clear all') is nearly identical to the schema's description. It adds minimal new meaning beyond the schema, so a baseline score of 3 is appropriate.
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 uses a specific verb 'Delete' and clearly identifies the resource as 'stored signals and spectra'. It distinguishes this tool from sibling tools like list_stored_data (read) and load_signal_from_file (load).
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 explicitly states when to use each variant: pass a specific data_id to remove one item, or omit to clear all. It does not mention exclusions or alternatives, but the instructions are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a non-destructive computation but does not explicitly state lack of side effects or permissions needed. Adequate for a calculation tool, but could be more transparent about safety (e.g., read-only, no data mutation).
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?
Three sentences, front-loaded with purpose, then details, then usage hint. No filler or redundancy. Every sentence adds value.
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?
With an output schema present, no need to explain return values. Covers fault types and usage context. Could mention prerequisites (e.g., motor parameters) or that it is specific to induction motors, but overall sufficient for a compute 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%, so the schema already describes all parameters. The description adds no additional meaning beyond listing fault types. Baseline score of 3 is appropriate as description does not enhance parameter understanding.
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?
Clearly states the verb 'calculate' and the resource 'expected fault frequencies' with specific fault types (broken rotor bars, eccentricity, stator faults). Distinguishes from sibling detection tools by focusing on frequency computation rather than fault detection.
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?
Provides an explicit usage hint: 'Use these frequencies to know WHERE to look in the current spectrum.' This implies it is a preprocessing step for spectral analysis. However, it does not explicitly state when not to use this tool versus siblings like detect_broken_rotor_bars, though the distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the full pipeline: reads, preprocesses, computes spectrum, runs detectors, returns report. No annotations exist, so description carries full burden; it provides clear stepwise behavior, though it does not mention read-only nature or potential side effects.
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?
Extremely concise: two sentences and a line break. Front-loaded with the core action and key qualifiers ('one-shot'), with no unnecessary wording.
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 (10 parameters, many siblings, output schema available), the description covers the essential function and workflow. It does not explain relationship with siblings, but the output schema existence reduces the need for return value description.
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 does not add extra parameter meaning beyond what the schema already provides, staying at the baseline.
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?
Clearly states the tool loads a signal from file and runs the full MCSA diagnostic pipeline. Uses specific verb 'diagnose' and resource 'from file', distinguishing it from siblings like 'run_full_diagnosis' which may not involve file loading.
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?
Describes as a one-shot tool ideal for batch/automated workflows, implying when to use. However, it does not explicitly state when not to use or mention alternative tools for partial steps (e.g., inspect_signal_file, preprocess_signal), leaving the agent without clear exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions return format and spectrum_id preference but lacks disclosure on side effects, safety (read vs write), or any limitations. Adequate but not rich.
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?
Extremely concise: first sentence states purpose, second clarifies return format. No wasted words, front-loaded.
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 9 optional parameters and an output schema, the description covers purpose and output format. Could elaborate on parameter interactions or provide a brief usage example, but overall sufficient.
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% with good descriptions. The description adds extra context like 'spectrum_id is preferred over raw arrays' and mentions output sorting. This adds value 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 the tool detects peaks in a frequency spectrum and specifies the output is sorted by amplitude with frequency, amplitude, and prominence. This is specific and distinguishes from sibling tools like compute_spectrum or detect_bearing_faults.
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 after computing a spectrum but provides no explicit guidance on when to use vs alternatives, no exclusions, and no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions waveform components but omits behavioral details like output format (handled by output schema), randomness, or performance. Adequate but not comprehensive.
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?
Two concise sentences, front-loaded purpose, no redundancy. Efficiently conveys essential information.
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?
With 8 optional parameters and an output schema, description covers signal components. Could mention output structure briefly, but overall sufficient for the task.
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%, baseline is 3. Description adds overall context but does not elaborate on individual parameters beyond schema defaults. No added semantic value.
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 'generate' and resource 'synthetic motor-current test signal', specifying components (fundamental, harmonics, noise, optional faults). Distinct from sibling analysis tools.
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?
States usefulness 'for testing, validation, and demonstration of MCSA analysis tools', providing clear context. Lacks explicit when-not-to-use or alternatives, but sufficient given siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the pipeline stages (preprocessing → spectrum → fault detection) and lists the specific fault types analyzed. This provides good behavioral transparency beyond a basic purpose statement. However, it does not mention prerequisites, side effects (e.g., data storage), or authorization needs, which are not covered by annotations (none provided).
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 concise, with three sentences that front-load the main purpose, then detail the pipeline and optional bearing analysis, and finally state the output format. Every sentence adds value without redundancy.
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 (8 parameters, many siblings, output schema exists), the description is adequate. It conveys the pipeline and fault types covered. However, it could hint at the preferred parameter (signal_id over signal) and describe the report contents more explicitly, though the output schema may cover that.
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?
The input schema has 100% description coverage for all 8 parameters, so the baseline is 3. The description adds no additional parameter-specific meaning beyond the schema, such as clarifying that signal_id is preferred over signal or how tolerance_hz is used.
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 explicitly states the tool runs a comprehensive MCSA diagnostic analysis on a current signal and lists the pipeline steps (preprocessing, spectrum, fault detection for specific faults). This clearly distinguishes it from sibling tools like detect_broken_rotor_bars or compute_spectrum, which focus on single steps.
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 when a full diagnostic is needed but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings. No alternatives are mentioned, and there is no direct comparison to tools like detect_broken_rotor_bars or compute_spectrum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the algorithmic steps (Hilbert transform, FFT) and purpose, but does not disclose potential side effects (e.g., whether it modifies state) or input requirements beyond schema. Still, it gives sufficient behavioral context for a computational tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and uses three sentences to cover method and use case. It is efficient but could be slightly tighter by merging the algorithm and purpose sentences. No wasted words.
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 6 parameters, an output schema, and no required fields, the description is complete. It explains the tool's purpose, method, and typical application. The output schema covers return format, so no further detail needed. Description adequately informs selection and invocation.
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 adds no additional insight into parameters beyond what the schema already provides. It does not explain how parameters like bandpass cutoffs relate to the algorithm, so no extra value.
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 computes envelope spectrum of a current signal using Hilbert transform and FFT. It distinctly specifies the resource (current signal) and action, differentiating it from sibling tools like compute_spectrum and compute_power_spectral_density which analyze different aspects.
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 explicitly mentions usefulness for detecting bearing and mechanical faults that modulate current at low frequencies, providing context for when to use. However, it does not directly contrast with siblings or state when not to use, missing full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the five-step processing pipeline (DC offset removal, notch, bandpass, normalization, windowing) and states return value. Lacks specific side effects or permission requirements, but adequate.
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?
Very concise: two sentences plus a numbered list of steps. Front-loaded with purpose, no wasted words. Every sentence adds value.
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 parameter count (7) with full schema coverage, output schema exists, and the processing pipeline is described, the description is fairly complete. Could mention constraints like signal length requirements or error handling.
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%, so baseline 3. Description does not add new meaning beyond parameter descriptions in the schema. The listed steps paraphrase param purposes but no additional semantics.
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?
Clearly states the tool preprocesses a stator-current signal for spectral analysis, listing the sequence of operations. Distinguishes from sibling spectral analysis tools like compute_spectrum by being the preparatory step.
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?
Implied usage: preprocessing before spectral analysis. No explicit when-to-use or alternatives, but context from sibling tools makes it clear. Missing explicit guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses two critical behaviors: (1) if target_freq_hz is provided, the tool tracks that frequency's amplitude over time, and (2) it returns a summary (not the full 2D matrix) to keep output manageable. This adds significant value beyond the input schema.
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 concise (4 sentences) and front-loaded with the main purpose. Every sentence contributes unique information: the core operation, the use case, the optional frequency tracking, and output format caveat. No unnecessary words or repetition.
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 the tool's complexity (STFT, frequency tracking, summary output) and the presence of an output schema (indicated in context signals), the description adequately covers what the tool does, when to use it, and key behavioral nuances. The output schema likely handles return value details, so this description is sufficiently complete.
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%, so baseline is 3. The description adds meaning: precludes signal_id over raw array, notes auto-resolution of sampling_freq_hz when using signal_id, explains target_freq_hz tracks a specific frequency, and implies tolerance_hz is for tracking. This compensates well beyond schema descriptions.
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 computes STFT for time-frequency analysis, specifically for non-stationary conditions. This distinguishes it from sibling tools like compute_spectrum (likely for stationary signals) and compute_power_spectral_density. The verb 'compute' and resource 'Short-Time Fourier Transform' are specific and unambiguous.
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 explicitly mentions 'For non-stationary conditions (variable speed/load, start-up transients)', providing clear context for when to use the tool. While it does not explicitly state when not to use or name alternatives, the given context effectively guides the agent toward appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations are absent, the description clarifies the tool does not fully load the file and returns metadata. It implies read-only behavior but could be more explicit about side effects (none).
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 concise with two sentences and a bullet list, front-loading the purpose and using no redundant words.
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 the tool has one parameter, 100% schema coverage, and an output schema exists, the description adequately explains purpose, usage, and return values. It is complete for a simple inspection 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?
The input schema already covers the 'file_path' parameter with 100% description coverage. The tool description adds the file formats (CSV, WAV, NPY) but does not provide additional constraints or examples.
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 inspects a signal file without full loading and returns specific metadata. It distinguishes itself from the sibling 'load_signal_from_file' by explicitly recommending use before loading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool before 'load_signal_from_file' to verify format and plan loading parameters, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns only summaries, not raw data, and data persists across restarts. It implies a read-only, non-destructive operation.
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?
Two sentences, no wasted words. The verb 'list' is front-loaded, and each sentence adds specific value: one defines the scope, the other clarifies output format and persistence.
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 zero parameters and the presence of an output schema, the description covers the essentials. It could have mentioned that this is a safe read operation, but the verb 'list' implies that. It is complete enough for effective agent use.
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?
There are no parameters, so the baseline is 4. The description does not need to add parameter info, and it correctly describes the output scope without needing to detail inputs.
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 lists signals and spectra stored on disk, specifies the output is a compact summary (ID, type, size, key metadata), and distinguishes from tools like clear_stored_data that modify data.
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 purpose is clear: use when you need to see what data is stored. There are no parameters or siblings with similar listing behavior, so no exclusions needed. The context is well understood.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: how sampling frequency is determined per format (inferred, auto-detected, required), supported file types, and the exact return values (signal, frequency, samples, duration, metadata). No contradictions.
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 concise: one sentence for the main purpose, then bullet points for format-specific details, and a closing sentence on return values and downstream use. No fluff, all sentences add 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 8 parameters (1 required), output schema exists, and no annotations, the description covers all needed information: file formats, parameter usage per format, return values, and integration with other tools. Complete for a loading 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% with detailed descriptions. The description adds format-specific context (e.g., CSV time column, WAV channel, NPY frequency requirement) that groups parameters logically, providing extra clarity beyond the schema alone.
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 loads a motor-current signal from CSV, WAV, or NPY files. It distinguishes itself by mentioning downstream tools (preprocess_signal, compute_spectrum, run_full_diagnosis), showing its role in a pipeline. This differentiates it from siblings like inspect_signal_file.
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 explains when each format is appropriate and when sampling frequency is required (e.g., for NPY it must be provided). It implicitly guides usage via format-specific details but does not explicitly state when not to use this tool (e.g., for metadata-only tasks use inspect_signal_file). Still, context is clear for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

mcp-motor-current-signature-analysis MCP server

Copy to your README.md:

[![mcp-motor-current-signature-analysis MCP server](https://glama.ai/mcp/servers/LGDiMaggio/mcp-motor-current-signature-analysis/badges/card.svg)](https://glama.ai/mcp/servers/LGDiMaggio/mcp-motor-current-signature-analysis)

Score Badge

Copy to your README.md:

[![mcp-motor-current-signature-analysis MCP server](https://glama.ai/mcp/servers/LGDiMaggio/mcp-motor-current-signature-analysis/badges/score.svg)](https://glama.ai/mcp/servers/LGDiMaggio/mcp-motor-current-signature-analysis)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LGDiMaggio/mcp-motor-current-signature-analysis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server