arimair-mcp

Official

by arim-science

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Multiple tools overlap in purpose, especially around data queries: data_recent vs device_realtime, monitor_search vs data_search vs data_raw_search vs stat_daily_avg, and monitor_rose vs monitor_rose_search. Descriptions clarify some differences, but several tool boundaries remain unclear and could easily cause misselection.
Naming Consistency3/5
Most tool names use snake_case with domain prefixes like device_, data_, stat_, correction_, report_, and monitor_, which provides structure. However, action verbs are inconsistent and some names are non-verb nouns or adjectives such as data_recent, monitor_rose, correction_factors, and report_v2_html, making the pattern less predictable.
Tool Count2/5
With 36 tools, the server exceeds the 25+ threshold and feels heavy. Several tools could be consolidated, such as the realtime variants, rose variants, and overlapping period-based data query tools, even though the overall domain is fairly broad.
Completeness4/5
The tool set gives broad read coverage for authentication, site/device context, raw and aggregated measurements, corrections, reports, and alarms. The lack of create/update/delete operations is acceptable for a monitoring-focused server, though alarm config is read-only and some reporting workflows are only partially surfaced.
Average 3.6/5 across 36 of 36 tools scored. Lowest: 2.9/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates that the tool queries data for a specified period. It does not disclose return format, pagination, ordering, limits, authentication needs, or any other behavioral traits.
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 a single, front-loaded sentence with no filler words. It communicates the core action and resource directly, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a minimal description. It does not explain what the returned pollution rose data looks like, what units or aggregation are used, or how this search differs from closely related search tools. More context is needed for correct invocation and result interpretation.
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 schema already documents both parameters with formats. The description adds no new parameter-level meaning beyond confirming a date range, which matches the baseline of 3.
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 states a clear verb ('조회한다' = retrieves) and a specific resource ('오염장미도 데이터' = pollution rose data) for a date range. However, it does not distinguish itself from the sibling tool 'monitor_rose', so it falls short of full sibling differentiation.
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?
The description gives no guidance on when to choose this tool over alternatives such as 'monitor_rose', 'monitor_search', or 'data_search'. It implies usage for a date-range query but never states exclusions or conditions.
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 are provided, so the description carries the full burden of behavioral disclosure. It reveals only that results follow monitoring-screen criteria (undefined) and are period-based; it is silent on read-only nature, pagination via maxRows, result shape, ordering, and how this differs from raw queries. The read verb implies safety but does not state it.
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?
A single dense Korean sentence with zero filler, repetition, or schema echoing. The verb and resource are front-loaded and the qualifying constraint follows naturally. It is appropriately sized, though there is no additional structure to organize usage or behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must independently explain behavior and return semantics. It leaves the meaning of 'monitoring criteria' vague, does not mention that maxRows controls result truncation (default 500), and says nothing about the response format. For a data-query tool with four parameters, this is a significant gap.
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 all four parameters (deviceId, startDate, endDate, maxRows) already carry types, formats, and constraints in the schema. The description only restates the device and period concepts without adding new format, default, or interaction details, so the baseline 3 for fully covered schemas is correct.
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 uses a specific verb (조회한다 - retrieves) with a defined resource (측정기의 기간별 데이터 - device's period-based data), and adds a distinguishing qualifier 'same criteria as the monitoring screen.' However, it does not explicitly differentiate itself from sibling tools like data_search or monitor_rose_search, and the 'monitoring criteria' itself is left undefined.
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 when-to-use or when-not-to-use guidance is provided, and no alternative tools are referenced. The phrase 'same criteria as the monitoring screen' implies a usage context, but it does not help an agent choose between this and the many sibling data/monitor/search tools, nor does it state any exclusions.
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 are provided, so the description carries the full burden of behavioral disclosure. It only says '조회한다' (query), indicating a read operation, but gives no details about whether it depends on a selected site, whether it is current or historical, or what exactly the returned rate represents.
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 a single short sentence with no filler or redundant information. It is front-loaded and easy to parse, though it is terse enough that some behavioral context is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no schema complexity, the description lacks important context such as whether the result is a single aggregate percentage, per-device values, or dependent on an active site selection. With no output schema and no annotations, this leaves the agent guessing about the return shape and prerequisites.
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?
The input schema has zero parameters, so there is no parameter ambiguity for the agent to resolve. The baseline score of 4 applies because no parameter documentation is needed.
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 states a specific verb and resource: it queries the normal operation rate of measuring instruments. This is clear enough in isolation, though it does not explicitly differentiate itself from the many sibling monitor_* tools.
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?
There is no guidance about when to use this tool versus monitor_device_state, monitor_fault_devices, monitor_data_count, or other related siblings. The intended use is only implied by the tool name and the phrase '정상 가동률'.
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 are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not explain ordering, date filtering, pagination beyond maxRows, or whether results depend on context like the currently selected site.
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 a single short sentence that conveys the core purpose without wasted words. It is appropriately sized for a simple read-only list tool.
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 tool is simple with zero required parameters and full schema coverage for the one optional parameter, so the description is minimally viable. However, it omits practical context such as whether alarm history is scoped by site or time and what the response shape looks like, which an agent might need to invoke it confidently.
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 only parameter, maxRows, is fully documented in the input schema with its default and constraints. The description adds no semantic value beyond the schema, so the baseline score of 3 applies.
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 Korean description states a clear verb and resource: '조회한다' (retrieve/query) and '발생한 알람 이력' (occurred alarm history). It is specific enough to identify what the tool does, though it does not explicitly compare itself with siblings like alarm_config_list.
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?
There is no guidance on when to use this tool versus alternatives such as alarm_config_list or monitor_* tools. It does not mention any preconditions, required context like a selected site, or situations that would make another tool a better fit.
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 are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool retrieves correction factors; it does not mention response format, result structure, scope limitations, or any side effects. This is minimal and leaves important behavioral context undisclosed.
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 a single short, clear sentence in Korean that front-loads the core purpose. There is no redundant wording, and every word contributes to understanding what the tool does.
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 tool is simple with only two well-documented parameters, but there is no output schema and no description of the return value or how the retrieved correction factors are presented. For an agent to confidently use the result, some additional context about output shape or behavior would be beneficial.
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%, with both deviceId and applyMonth already documented in the schema. The description adds little semantic value beyond 'specific application month,' so the schema carries the parameter-documentation burden and the baseline of 3 is appropriate.
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 a specific action and resource: it retrieves correction factors used in a specific application month. However, it does not explicitly distinguish itself from sibling correction-related tools such as correction_trend, correction_compare, or correction_versions, so it is clear but not fully differentiated.
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 about when to use this tool versus the many sibling correction tools. There is no mention of scenarios, exclusions, or alternatives, leaving the agent to infer appropriateness from the tool name and description alone.
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 implies a read-only query operation, which is a useful behavioral signal. However, with no annotations provided, the description carries the full burden and does not explain the meaning of 'recent', the ordering of results, or any limits beyond the schema's maxRows field. It does not contradict any annotations.
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 a single, focused sentence with no filler or redundancy. It is front-loaded with the key verb and resource, though it is arguably too terse to fully equip an agent navigating a large set of sibling data tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and it sits among many data-related siblings. The description does not clarify the recency window, whether results are time-ordered, what fields are returned, or how this tool differs from data_search and device_realtime, leaving important selection and invocation context missing.
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 parameters deviceId and maxRows are already fully documented in the schema. The description adds no additional meaning about how the parameters interact with 'recent' data, which is acceptable but does not exceed the schema's contribution.
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 a specific action ('조회한다' / retrieves) and a specific resource ('측정기의 최근 수집 데이터' / recent collected data for a measuring device). However, it does not explicitly differentiate itself from sibling tools such as data_search, data_raw_search, or device_realtime, so an agent must infer the distinction.
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 instead of alternatives like data_search, data_raw_search, or device_realtime. There are no exclusions, conditions, or mention of related tools that might better suit a different request.
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 are provided, so the description carries the full burden of behavioral disclosure. It only says '조회한다' (queries), which is a read operation, but it does not explain scope, whether the result is global or site-specific, whether data is cached, or what aggregation window is used. Beyond the basic read implication, no useful behavioral context is added.
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 a single compact sentence with no filler or redundant clauses. It is front-loaded with the action and object, which is appropriate for such a simple no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter constraints, the description still leaves important ambiguity: what exactly is counted, over what time period, and for which scope? Because sibling tools like stat_collection_rate and data_recent overlap conceptually, more context is needed for reliable selection and interpretation of the result.
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?
The tool has zero parameters and the schema is vacuous, so there is no parameter detail for the description to add. The schema already covers 100% of the parameter space, and the baseline of 4 applies for a no-parameter tool.
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 states a specific verb ('조회한다' / retrieves) and a specific resource ('데이터 수집 건수 집계' / data collection count aggregation), so an agent can tell this is a count-query tool. It does not explicitly contrast it with siblings such as stat_collection_rate or data_recent, so it is clear but not fully differentiated.
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 about when to use this tool rather than a sibling like data_recent, stat_collection_rate, or monitor_device_state. There are no stated alternatives, exclusions, or conditions that would help an agent decide between similar monitoring 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 are provided, so the description must carry the behavioral burden. It only conveys read-only intent via '조회한다' and does not disclose response behavior, aggregation semantics, output contents, or constraints.
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?
A single Korean sentence states the action and defines the term '오염장미도' with the parenthetical '풍향별 농도 분포'. It is compact, front-loaded, and contains no filler.
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 low complexity and clear schema make the one-sentence description minimally adequate. However, without an output schema or annotations, the returned data shape and any usage conditions remain unspecified, and the relationship to monitor_rose_search is not addressed.
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%; the only parameter period is documented in the schema with its enum values and '집계 구간' meaning. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
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 uses an explicit verb '조회한다' and identifies the resource as '오염장미도(풍향별 농도 분포) 데이터', making the core function clear. However, the nearby sibling monitor_rose_search implies a similar lookup role, and the description does not explicitly disambiguate the two.
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 about when to use this tool versus monitor_rose_search or other monitor_* siblings. The agent is left to infer usage from the tool name and schema alone.
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 the burden of behavioral disclosure. It usefully reveals server-side automatic unit conversion with thresholds, but does not mention read-only safety, sampling behavior beyond schema hints, authentication needs, or result characteristics.
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?
A single well-structured Korean sentence front-loads the core action and immediately provides the key behavioral thresholds. No filler or redundancy.
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 is adequate for a simple period-based query, and the schema fully documents parameters. However, there is no mention of alternative tools, output shape, or safety implications, which leaves some contextual gaps.
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 meaning to the period parameters by explaining that the selected range determines aggregation unit, but it does not provide additional syntax or formatting details beyond the schema.
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 the tool retrieves measurement data by period, with a specific verb and resource. The automatic unit conversion detail helps differentiate it from raw-data siblings, though no sibling tool is explicitly named.
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 about when to use this tool versus alternatives like data_recent or data_raw_search. The description only explains behavior after invocation, not selection criteria or exclusions.
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 the full behavioral burden. The verb '조회한다' suggests a read-only query and '상세 정보' indicates the kind of result returned, but the description does not mention permissions, error behavior, response shape, or side-effect guarantees.
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?
A single, efficient declarative sentence with no filler. The action and scope are front-loaded: '조회한다' and '한 대의 상세 정보'.
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?
Adequate for a simple one-parameter read tool, but the absence of an output schema leaves 'detailed information' undefined. It also offers no context to help an agent decide when this tool is more appropriate than related device tools.
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%: the only parameter, deviceId, is already documented with a type and example ('예: D0517'). The description adds no extra meaning to the parameter, so the baseline of 3 is appropriate.
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?
States a clear verb and resource: '조회한다' (retrieves) and '측정기 한 대의 상세 정보' (detailed information of one measuring device). The phrase '한 대' implies singular scope, which helps distinguish it from device_list, but it does not explicitly name sibling tools.
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?
Provides no guidance about when to use this tool versus siblings such as device_list, device_realtime, or device_nearby_stations. There is no context about prerequisites, alternatives, or exclusions.
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?
Since no annotations are present, the description carries the behavioral disclosure burden. It does state that the operation is a read/query ('조회한다') of a single detail, which implies it is not destructive and not a list operation. However, it does not describe response shape, error cases, or access implications.
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 a single, concise sentence with no filler. Every word contributes meaning, and the core action and resource are front-loaded.
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?
For a simple one-parameter read tool, the description plus the schema is enough to know how to invoke it: call with a report history number. However, with no output schema and no annotations, it leaves the agent to infer what the returned 'detail' contains and what failure modes might occur.
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 schema already documents the only parameter 'no' fully as '리포트 이력 번호(no)' with 100% coverage. The description adds no additional parameter semantics beyond the overall action, so the baseline of 3 applies.
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 uses the specific verb '조회한다' (retrieves) with a precise resource: '리포트 발행 이력 한 건의 상세' (a single report publication history detail). This clearly indicates a get-one-item operation and distinguishes it from list-oriented siblings like report_list, though it does not explicitly name the sibling.
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 about when to use this tool rather than report_list, report_months, or report_v2_html. There is also no mention of a prerequisite such as obtaining the history number from a list call first.
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 present, so the description carries the full burden. The verb '조회한다' implies a read-only query, but the description does not explicitly state side effects, auth requirements, or output structure. It discloses the subject matter but lacks deeper behavioral context such as whether results are ordered, paginated, or scoped.
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?
A single concise Korean sentence that efficiently states the action and the target resource. There is no redundant or filler text, and the core purpose is front-loaded.
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 no parameters and no output schema, the description is the primary spec. It clearly states what is retrieved, but it leaves some ambiguity about the exact composition of the result (e.g., whether 'list' and 'status' are separate fields or one combined view). A slightly richer description would make the response shape clearer, so it is adequate but not 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?
The tool has zero parameters and schema description coverage is 100% (vacuously). With no parameters to document, the description need not add parameter semantics; the baseline of 4 for a zero-parameter tool is appropriate.
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 uses a specific verb '조회한다' (queries/retrieves) and names a concrete resource: the list of correction-target measuring instruments and their correction application status. This distinguishes it from sibling tools like correction_factors or correction_trend by scope, though it does not explicitly name any alternative.
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 correction_factors, correction_trend, or correction_versions. There are no conditions, exclusions, or context clues about the intended use case.
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 the transparency burden. '조회한다' implies a read-only query and '집계' indicates aggregated output, which is useful. However, it does not disclose whether the result is real-time or historical, how statuses are represented, or whether any side effects or prerequisites exist.
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 a single, compact sentence that front-loads the subject and action. There is no filler, redundancy, or unnecessary detail.
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?
For a zero-parameter tool, the description is adequate to start a call, but there is no output schema and no annotation context. It would be more complete if it described what the aggregate contains, such as counts of running/stopped/faulty devices or a time scope. The absence of that detail leaves the agent guessing about the return value's meaning.
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?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it does not introduce any confusion about required inputs.
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 names the operation ('조회한다' / query) and the resource ('측정기 가동/통신 상태 집계' / device operation-communication status aggregate). It is specific enough to convey the tool's core purpose, but it does not explicitly differentiate this from closely related sibling tools like monitor_working_percent or monitor_data_count.
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 about when to prefer this tool over its many siblings. The description implies it is for querying device status aggregates, but it never states what scenario this fits, what alternatives exist, or what excludes using this tool.
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 verb '조회한다' indicates a read-only operation, and the parenthetical describes returned fields. However, with no annotations, the description does not disclose whether authentication or a selected site is required, nor any ordering or pagination behavior, leaving some behavioral traits undocumented.
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 a single compact sentence that states the operation and the relevant output fields without filler. It is appropriately sized for a zero-parameter list tool.
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?
For a simple zero-parameter listing tool, the description covers the operation and output fields. However, the sibling set includes login and site-selection tools, suggesting session context may be a prerequisite, and the description does not mention authentication, scope, or ordering, which leaves a minor completeness gap.
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?
The input schema has zero parameters and 100% schema-description coverage, so the baseline is 4. The description adds useful output-field context but there are no parameters for it to explain.
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 uses a specific verb ('조회한다') and a clear resource ('리포트 발행 이력'), and lists the fields returned. It is clearly a report-history listing operation, though it does not explicitly differentiate itself from sibling tools such as report_get or report_months.
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 about when to use this tool instead of alternatives like report_get or report_months. Prerequisites such as login or site selection are also not mentioned, so the agent must infer usage purely from the name and sibling context.
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 provided, the description carries the full burden. It discloses that the operation is a read-oriented query and adds the 12-month scope, but it does not describe the output format, ordering, grouping, or any other behavioral details. This is 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?
The description is a single, well-structured sentence that front-loads the resource and time scope. Every word earns its place, with no redundancy or filler.
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 is minimally viable for invoking the tool: it states purpose, scope, and the 12-month window, and the schema covers parameters. However, since there is no output schema, it would be stronger if it described what the returned trend data looks like or how it relates to siblings like correction_factors.
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 input schema already documents both parameters. The description does not add parameter-specific semantics beyond implying that the trend is filtered by device and possibly by measurement item, which is baseline acceptable.
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 uses a specific verb ('조회한다', meaning queries/retrieves) and names the resource ('측정기의 보정 인자 변화 추이'), including an explicit 12-month time window. It clearly conveys what the tool does, though it does not explicitly distinguish it from sibling correction-related tools.
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 implicitly indicates when to use the tool: when a recent 12-month correction factor trend is needed. However, it provides no explicit guidance about when not to use it or which sibling tool (e.g., correction_factors, correction_compare) should be chosen instead.
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?
There are no annotations, so the description carries the full burden. The verb '조회' clearly implies a read-only query, which offers some transparency, but the description does not disclose whether login is required, how current the 'latest' data is, whether the correction computation has side effects, or any rate limits or performance considerations.
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?
A single, well-structured sentence that states the action, scope, and nature of the result. There is no fluff, and the key qualifier '보정 적용값' is included, making it an efficient and front-loaded description.
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 zero parameters, the tool is trivially invocable, and the description names the returned data (latest corrected values for all devices). However, because there is no output schema, it does not describe the shape of the return value, and it omits any mention of authentication or preconditions, leaving the context only partially 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?
The input schema has zero parameters and schema coverage is effectively 100%. Per the rubric, 0 parameters warrants a baseline of 4, and there are no parameter semantics for the description to explain or clarify.
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 '조회한다' (retrieves/queries) with a clear resource: the latest measurement values of all measuring instruments. The qualifier '보정 적용값으로' (as correction-applied values) distinguishes this from siblings like device_realtime and correction_factors, which likely return raw values or correction factors themselves.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools, conditions, exclusions, or prerequisites such as authentication or site selection. The only usage indication is implicit in the stated purpose.
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 present, so the description carries the full burden. It clearly indicates a read-only operation and a list result, but does not disclose potential authentication requirements, ordering, or the exact composition of the month list. For a zero-parameter read tool, this is minimally 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?
A single clear sentence in Korean that front-loads the action and resource with no filler. It is appropriately concise for the tool's simplicity.
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 that there are no parameters and no output schema, the description sufficiently states what the tool returns: a list of months eligible for report publication. Minor ambiguity remains about the exact criteria for a 'target month,' but the tool can be invoked correctly.
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?
The tool has zero parameters, so the schema is trivially fully covered. The baseline for zero parameters is 4, and the description correctly implies no inputs are needed.
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 uses a specific verb ('조회한다' - retrieves) and a clear resource: the list of target months for which reports can be published. It is distinguishable from report_list/report_get siblings, though it does not explicitly contrast with them.
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. The purpose implies it should be used before publishing a report, but no exclusions, prerequisites, or alternative routing are provided.
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 are provided, so the description carries the full burden. It only implies a read-only query via '조회한다', but discloses no return format, pagination/filtering behavior, or limitations. For a tool with no annotation coverage, this is a significant gap.
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 short sentences with no fluff; the core action is front-loaded and the use case sentence earns its place. Very concise and well-structured.
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 is adequate for a simple query tool, and the schema covers parameters. However, without an output schema or any mention of return structure, aggregation details, or differentiation from sibling stat_* tools, some 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 description coverage is 100%, so all parameters are already documented. The description adds general context but no parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.
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 states a specific verb '조회한다' (queries) and a specific resource: data collection rate (missing rate) by meter and date. It also states the intended use case, identifying missing sections. It does not explicitly distinguish this tool from siblings, so it stops short of a 5.
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 gives clear usage context: '결측 구간 파악에 쓴다' (used for identifying missing sections). It does not name alternatives or when not to use it, but the purpose is specific enough for an agent to infer when it applies.
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 the burden; it does convey read-only behavior via 조회한다 and historical scope via 관측 이력, which adds context. However, it omits authentication needs, rate limits, and how missing or incomplete observations are handled, with no output schema to fill in the gap.
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 a single Korean sentence with no filler; the resource, data fields, and granularity are all front-loaded. Every word contributes to the agent's understanding.
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 purpose is adequately stated and the schema covers all five parameters, but with no annotations and no output schema, the description leaves out response structure, default behaviors, and alternative routing. It is sufficient for a simple read-only query but has clear gaps.
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 parameter-specific detail beyond what the schema already documents. The mention of hourly/daily reinforces the mode parameter but does not enhance meaning.
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 a specific verb (조회한다 – queries), a concrete resource (기상청 관측 이력 – KMA observation history), and the available granularity (hourly/daily). This distinguishes it from sibling tools like stat_weather_stations or stat_daily_avg, which revolve around station metadata or daily averages.
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?
The description offers no guidance on when to use this tool versus alternatives such as data_raw_search or stat_daily_avg, and no prerequisites or exclusions are mentioned. Usage must be inferred solely from the purpose statement.
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 provided, the description carries the full burden. It does disclose the side effect of creating a session and the env-var fallback behavior, which is useful. However, it does not disclose how long the session lasts, whether existing sessions are invalidated, what happens on failure, or whether credentials are stored or transmitted beyond the fallback.
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 short, focused sentences. The primary action and target are front-loaded, and the parameter fallback is stated immediately after. There is no filler or repetition of schema details.
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 the core purpose and parameter behavior, but since there is no output schema and no annotations, it omits the login response format, the session mechanism, and typical error conditions. Given the low complexity (3 optional params, no nested objects), this is adequate but not fully complete for an agent that needs to rely on the tool correctly.
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%, so the baseline is 3. The description adds genuine value by explaining that omitted arguments fall back to ARIM_MCP_USER/ARIM_MCP_PASS environment variables, which is behavioral information beyond the raw property descriptions for userId and password.
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 the verb '로그인해' (log in) and the resource 'ARIM 모니터링 서버' (ARIM monitoring server), and it clarifies the outcome: creating a session. It is not a tautology and is distinguishable from siblings like arim_logout and arim_whoami, though it does not explicitly name those siblings.
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 the tool is used to establish a session, which is a prerequisite for other ARIM tools. It provides a concrete usage hint about environment variable fallback when arguments are omitted, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or when a login is unnecessary.
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 provided, the description bears the full burden of behavioral transparency. It tells the agent this is a read-only comparison view of pre/post correction time series, which implies non-destructive behavior. However, it doesn't disclose details like pagination behavior, result ordering, timezone handling, or whether it returns both series merged or separate. For a read-only lookup tool, this is acceptable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence in Korean that states what the tool does and its purpose. It is appropriately short and front-loaded with the action. It could optionally mention parameter constraints, but for a lookup tool with a 100% schema coverage, this length is appropriate.
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?
For a tool of this complexity (4 params, no output schema, no nested objects), the description conveys the core purpose and use case but doesn't clarify what the output structure looks like. Without an output schema, a note about the result format (e.g., columns, how before/after series are represented) would improve completeness. Sibling tools like correction_trend and correction_devices exist, but the description doesn't explain how this tool differs from them in terms of output.
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%, meaning all four parameters (deviceId, startDate, endDate, maxRows) already have descriptions in the schema. The description adds the contextual meaning that these parameters define the time series comparison (before/after correction), but doesn't add format or syntax details beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
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 states a specific verb ('조회한다' - retrieves/looks up) and resource ('보정 전/후 시간별 시계열' - time series before/after correction), and explicitly mentions its purpose ('보정 효과 검증에 쓴다' - used for correction effect verification). This provides a clear distinction from general data lookup tools like data_search or data_raw_search, though it doesn't name a sibling explicitly.
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 phrase '보정 효과 검증에 쓴다' (used for correction effect verification) gives clear context on when to use this tool. While it doesn't explicitly state when NOT to use it or name alternatives, the purpose statement is specific enough to guide an agent toward this tool for correction comparison scenarios and away from general data retrieval 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?
The description only states that a list is retrieved. With no annotations provided, there is no disclosure of behavior beyond the basic query action—such as whether it relies on a selected site context, authentication requirements, result limits, or ordering. The description carries the full burden and provides minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and front-loaded sentence that explains exactly what the tool returns without any filler or 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?
For a zero-parameter list retrieval tool, the description adequately communicates the returned entity type (fault/abnormal measurement devices). Some details such as output fields or scope are missing, but the low complexity and lack of parameters make the description reasonably 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?
The tool has zero parameters and the schema contains no properties, so there are no parameter semantics to document. The baseline of 4 applies because no parameter explanation is needed.
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 retrieves a list of measurement devices judged to be in a fault or abnormal state ('고장·이상 상태로 판정된 측정기 목록을 조회한다'). This is a specific verb + resource and is distinct among siblings, none of which explicitly target faulty devices.
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 like monitor_device_state, monitor_search, or other monitoring tools. The intended use is implied by the tool name and description, but there are no explicit usage conditions or exclusions.
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 provided, the description carries the full burden of behavioral disclosure. '조회한다' signals a read-only operation, and the arim_whoami reference reveals a dependency. However, it does not mention authentication requirements, return format, or error behavior, which remain undisclosed.
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 a single sentence with two tightly connected clauses: main purpose first, then default parameter behavior. There is no filler, and the information is front-loaded and scannable.
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 tool with one optional parameter and no output schema, the description covers the essential purpose and the critical default behavior of that parameter. It doesn't describe return values or auth prerequisites, but nothing beyond the session dependency is clearly required for a configuration-list read 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?
The schema already documents adminId, but the description adds meaning by stating that omitting adminId resolves to the monitorId from arim_whoami. This clarifies the 'current session' concept in the schema and exposes a specific cross-tool dependency, going beyond the schema's generic phrasing.
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 states a specific verb, '조회한다' (retrieves), and a specific resource, '센서 임계치 문자 알림 설정' (sensor threshold SMS notification settings). This makes the tool's function clear and distinguishes it from sibling tools like alarm_list by resource type, though it does not explicitly name alternatives.
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 gives a concrete usage hint: if adminId is omitted, the tool uses the monitorId from arim_whoami. This is useful for calling the tool correctly, but it does not state when to choose this tool over related siblings such as alarm_list or monitor_search, leaving tool-selection guidance implicit.
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 provided, the description carries the full burden of behavioral disclosure. It does state a read-only intent ('조회한다') and the nature of the returned data (version history with performance metrics), but it does not mention pagination, ordering, response shape, or any prerequisites. This is adequate for a simple lookup tool, though richer behavior context would be beneficial.
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 a single, focused sentence with no filler, redundancy, or unsupported claims. It conveys the core purpose efficiently and is appropriately front-loaded.
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?
For a 4-parameter query tool with no output schema and no annotations, the description provides only the essential purpose and omits usage context, default behavior, and differentiation from overlapping siblings like correction_trend or correction_compare. The schema covers parameter details, but an agent would benefit from explicit guidance on when to call this tool and how it relates to sibling tools.
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 schema description coverage is 100%, so the schema already documents all parameter semantics. The description adds no parameter-specific meaning beyond the schema, only indicating the overall output content of version history and metrics, which matches the baseline expectation.
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 the verb '조회한다' (query) with a specific resource '보정 모델의 버전 이력' (calibration model version history) and adds '성능 지표 포함' (including performance metrics), which clearly differentiates it from sibling tools like correction_factors or correction_trend. The resource is distinct and the scope is explicit even without naming an alternative.
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 provides no explicit guidance on when to use this tool versus alternatives such as correction_factors, correction_trend, or correction_compare. Usage context is only implied by the stated purpose of querying version history, so an agent must infer the appropriate situation from the tool name and description.
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 the full burden of behavioral disclosure. It reveals a key non-obvious behavior: the server automatically converts data granularity based on the requested period. This goes beyond the schema and helps the agent anticipate output granularity. It does not cover response format or pagination, but the disclosed auto-conversion is significant and valuable.
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 with no filler. It front-loads the core purpose ('queries average data by period') followed by a concise, high-value clarification of the auto-conversion logic. Every word earns its place and the structure is easy to parse.
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 the central behavior well, but the absence of an output schema or annotations leaves gaps: the agent does not know the shape of the returned data, whether maxRows interacts with the auto-conversion, or other response details. It is adequate for understanding the main logic but not complete enough for a fully informed call.
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%, so the baseline is 3. The description adds extra meaning to startDate and endDate by explaining how the date-range length determines the data granularity (raw, hourly average, daily average). This directly enhances understanding of the two key parameters beyond their simple type/format descriptions. Other parameters like maxRows and deviceId are not elaborated, but the schema already covers them well.
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 states a specific action: it queries average data over a period ('평균 데이터를 기간으로 조회한다'). It also explains the server's auto-conversion behavior, which adds clarity. However, it does not explicitly name or differentiate itself from sibling tools like data_raw_search or stat_weather, so it falls short of full distinction.
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 by explaining period-based granularity: raw for ≤1 day, hourly for ≤30 days, daily for >30 days. This gives context for choosing the tool based on date range, but it does not explicitly state when to use this vs. alternatives or provide exclusions. The guidance is implied, not direct.
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, the description carries the full burden of behavioral disclosure. It explicitly reveals the destructive side effects: terminating the session and discarding cookies. This is transparent for a logout operation, though idempotency and error behavior are not covered.
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?
A single, short Korean sentence conveys the complete behavior with no filler or repetition. It is front-loaded with the main action and easy to parse in one line.
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 zero-parameter, no-output-schema logout tool, the description is largely complete: it states what happens to the session and cookies. It omits minor details like post-logout request behavior or behavior when no session exists, but those are not critical for a simple logout call.
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?
The tool takes zero parameters, so the schema has no properties. The description correctly adds no parameter details, and the baseline for no-parameter tools is 4. No further explanation is needed.
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 the action ('세션을 종료' = end session, '쿠키를 폐기' = discard cookies) with specific verbs and resources. It inherently differentiates from arim_login and arim_whoami, though it does not explicitly name alternatives.
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 intended use is implied: call when the current session should be ended. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites like requiring an active session.
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 burden of behavioral disclosure. It does indicate a read-only lookup operation and enumerates the included output fields, which is useful. However, it does not mention pagination, ordering, auth requirements beyond login visibility, or any side effects, leaving the behavioral picture incomplete.
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 a single sentence plus a compact parenthetical field list. Every word adds value: the operation, the account scope, and the important returned data are all present with no filler or repetition.
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 that the tool has no parameters and no output schema, the field list in the description provides most of what an agent needs to know about the return value. It could be more complete with notes about ordering, pagination, or what the listed fields mean, but it is sufficient for a first call.
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?
The tool has zero parameters and the input schema has no properties, so schema coverage is effectively complete. The description has no parameter obligations, and it instead uses the space to describe output fields, which is appropriate.
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 states a specific operation—list measuring instruments—and gives the scope: devices visible to the logged-in account. It also lists the returned fields, which clarifies what kind of device list this is. It does not explicitly contrast with siblings like device_get or site_list, so it stops short of full sibling differentiation.
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 phrase 'devices visible to the logged-in account' provides clear context for when to call this tool: you need the account-scoped device list, not a single device or live stream. It does not mention alternatives or exclusive conditions, so it lacks the explicit when-not-to-use guidance that would earn a 5.
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 must disclose behavioral expectations. It conveys that the operation is a read ('조회'), returns a list, and is sorted by distance ('거리순'). However, it omits operational details such as authentication requirements, whether a valid session is needed, and what fields appear in the output. These gaps are meaningful given the absence of annotation coverage.
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 a single, compact sentence that front-loads the core operation and then gives a practical use case. There is no redundant phrasing or repetition of schema information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one fully documented parameter, no output schema, and no annotations, the description is fairly complete: it states that the result is a distance-ordered list of nearby Air Korea stations and provides a concrete use case. It lacks explicit notes on authentication or output fields, but these are less critical for a read-only lookup. The use case sentence gives enough context for correct 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?
The input schema fully documents the only parameter, deviceId, as '측정기 ID' (measuring device ID) with 100% coverage. The tool description does not add meaning beyond what the schema already provides; it only infers that this is the device whose nearby stations are retrieved. This is baseline value – no enhancement, no contradiction.
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 states a specific verb ('조회한다' – retrieves), a clear resource (Air Korea stations near the measuring device), and a sorting behavior ('거리순' – by distance). It also explicitly names a use case ('보정 기준국 확인에 쓴다' – used for checking calibration reference stations), which differentiates it from generic device or data-retrieval siblings. The purpose is unambiguous and action-oriented.
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 provides a clear usage context: it is meant for checking calibration reference stations. This tells an agent when this tool is appropriate without requiring inference. It does not explicitly mention alternatives or exclusions, but the specific use case sufficiently guides selection.
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 the transparency burden and does well: it discloses that a missing saved version triggers server-side generation and that LLM-based opinion generation can cause delays. This goes beyond the schema and is valuable operational context, though it does not cover failure modes or side effects in detail.
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?
A single compact sentence that front-loads the main purpose and then adds the two most important behavioral caveats: server generation on missing saved copies and potential slowness due to LLM opinions. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with a fully described schema and no output schema, the description gives enough to call it correctly: what it returns (HTML body), when it may be slow, and that it may trigger generation. A slightly richer statement about timeout behavior or response format would push it to 5, but nothing critical is missing for 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 the schema already documents all three parameters. The description adds no parameter-specific detail beyond the schema; the latency mention is related to generation behavior, not parameter semantics. A baseline of 3 is appropriate.
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 the verb '조회한다' (retrieve) and the specific resource: the HTML body of the new V2 report. It distinguishes this tool from generic report tools by emphasizing '신규 리포트(V2)' and 'HTML 본문', though it does not explicitly name a sibling alternative.
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 gives clear context: use this for the V2 report's HTML body and be prepared for longer latency if no saved version exists. It does not explicitly state exclusions or alternatives, but the V2 and HTML-body framing makes the intended use reasonably unambiguous among the sibling report tools.
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 available, the description carries the behavioral transparency burden. It discloses two significant behaviors: it always returns minute-granularity raw rows, and it bypasses statistics tables—a signal that result sets may be large and unfiltered. It does not mention auth, rate limits, or side effects, but the core query behavior is transparent enough.
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 short sentences front-load the main behavior (always minute-level raw data) and the key exclusion (no statistics tables). There is zero filler or redundancy, making it easy to parse quickly.
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?
For a query tool with no output schema and no annotations, this description gives a solid high-level purpose but omits the output shape, column list, ordering, pagination, and performance implications of querying raw data over an arbitrary period. The schema's maxRows parameter partially compensates, but an agent still lacks a complete picture of what a response contains.
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 schema already documents the parameters and their formats. The description adds only a general statement that the date range is unrestricted, but it doesn't deepen meaning about specific parameters like maxRows or date handling. The baseline 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 states a specific action ('조회한다' / query) and a specific resource ('분단위 원시 데이터' / minute-level raw data), and adds a key differentiator: it does not go through statistics tables. This makes it clearly distinct from statistical siblings like stat_daily_avg or data_recent, even without a tool title.
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 conveys clear usage context: use this tool when raw minute-level data is needed over any time period, and when aggregated/statistical processing is undesirable. It doesn't explicitly name alternative tools or state a when-not-to-use condition, but the contrast with statistics tables implicitly routes statistical queries elsewhere.
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 provided, the description must carry the burden of behavioral disclosure. The verb '조회한다' indicates a read-only operation, and the description lists what is returned. However, it does not mention authentication requirements, error behavior when not logged in, or other operational details, so transparency is 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?
The description is a single compact sentence with no filler or repetition. It front-loads the most important output, login status, and immediately explains the relevance of monitorId, making every phrase useful.
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 zero-argument tool with no output schema, the description reasonably conveys the main return areas: login state, current monitorId, and system settings. The term 'system settings' is somewhat vague, but in the context of sibling tools and the whoami-like name, the description is sufficiently complete for an agent to invoke it correctly.
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?
The tool has zero parameters and the input schema is empty, so there are no parameter semantics for the description to clarify. Per the calibration baseline, 0 params warrants a 4.
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 names a specific verb (조회한다, 'queries') and the exact resources it returns: current login status, the monitorId used as a filter basis, and system settings. This clearly separates it from sibling mutation tools like arim_login and arim_logout, which perform authentication actions rather than reading current context.
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 supplies clear contextual guidance by identifying that the returned monitorId serves as the basis for query filters, implying this tool should be called before filter-based data queries. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
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 clearly conveys a read-only query behavior, the 'all devices' scope, and the raw-value basis, which are the central behavioral traits. It does not mention output structure, authentication, or rate limits, but for a zero-parameter read tool these omissions are acceptable.
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?
One concise sentence with a short parenthetical qualifier delivers both the operation and the key data attribute. The information is front-loaded and there is no redundant or filler content.
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 zero-parameter read tool, the description covers what is returned (latest measurement values), the scope (all devices), and the value basis (raw, uncorrected). A small gap remains: it does not describe the response format or clarify whether 'all devices' means globally or within the current site context, but this is not critical for tool selection.
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?
The tool has zero parameters, so the input schema is trivially complete and the description has no parameter burden to carry. The baseline of 4 for zero-param tools applies; nothing extra is needed.
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 ('조회한다' / retrieves) and identifies the resource clearly: the latest measurement values from all measuring devices. The parenthetical raw-value note distinguishes it from corrected-value tools like device_realtime_correction, so an agent can tell which sibling is intended.
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 gives contextual signals by stating that values are raw and uncorrected, implying that a corrected-value tool would be a different choice. However, it does not explicitly state when to use this tool instead of alternatives such as device_realtime_correction or data_recent, nor does it provide exclusion criteria.
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 behavioral disclosure burden. It explicitly says '조회한다' (retrieves), indicating a read-only action, and additionally discloses a non-obvious formatting detail: the digit field uses values like 'F1' or 'F2', so only the numeric part should be used.
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 sentences with no filler. The main purpose is front-loaded, followed by the intended usage context and a useful formatting caveat, making every sentence earn its place.
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?
For a zero-parameter tool with no output schema, the description is complete: it names the returned fields, explains why the tool is used, and flags the digit-format quirk. Nothing essential is missing for an agent to invoke and interpret the result correctly.
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?
The tool has zero parameters and schema description coverage is 100%, so the baseline of 4 applies. The description does not need to explain parameter meaning because there are no parameters to document.
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 the tool retrieves sensor metadata including item id, name, unit, and decimal places. This is a specific verb+resource statement that distinguishes sensor_list from device_list or site_list, though it does not explicitly call out sibling alternatives.
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 says the metadata is used for interpreting and displaying measured values, giving clear context for when to call it. It does not mention exclusions or contrast with sibling tools, but for a zero-parameter metadata listing the implied usage is reasonably clear.
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?
There are no annotations, so the description carries full responsibility for disclosing behavior. It communicates that the operation is a read-only list retrieval, but does not mention authentication needs, pagination, freshness, or whether all stations or only active stations are included. The disclosure is basic but not misleading.
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 with no wasted text. The core action is front-loaded, and the usage purpose is stated immediately after. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter lookup tool, the description adequately conveys what is retrieved and why. It does not explicitly list the returned fields or mention authentication, but the stated purpose implies the important return value (stnId) and the tool's simplicity reduces the need for more detail.
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?
With zero parameters and 100% schema coverage, the schema already fully documents the input. The description adds the meaningful context that the tool exists to resolve stat_weather's stnId, which is the only relevant semantic needed to invoke it correctly.
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?
States a specific verb and resource ('기상청(KMA) 관측소 목록을 조회한다') and ties it to the exact purpose of finding stat_weather's stnId. This clearly distinguishes it from the many sibling list tools by naming both the source (KMA) and the intended consumer (stat_weather).
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 a clear context for use: when locating stnId for stat_weather. It does not explicitly mention when not to use it or name alternative tools, but the stated use case is sufficient for a simple lookup tool.
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 the full burden of behavioral disclosure. It communicates that the operation is a read-only retrieval and adds meaningful context about the currently selected site being the basis for all downstream queries. It does not cover edge cases such as empty lists or authentication failures, but for a simple zero-parameter lookup this is 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?
The description is two sentences with no filler. The primary purpose is stated first, and the second sentence adds genuinely useful context about why the returned current site matters. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter site-list lookup, the description is almost complete: it names what is returned (selectable sites plus current selection) and explains the significance of the current site. It does not detail the exact output structure, but without an output schema this is a minor gap rather than a functional blocker.
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?
The tool has zero parameters, so there is nothing for the description to clarify beyond the schema. The baseline for zero-parameter tools is 4, and the description does not introduce any confusing parameter-related claims.
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 states precisely what the tool does: it retrieves both the list of selectable sites and the currently selected site. The verb '조회한다' is specific, and the scope clearly distinguishes it from sibling tools like site_select, which handles selection rather than listing.
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 gives clear context: it should be used when an agent needs to know the available sites or the current site context. The statement that device, data, and report queries all operate on the current site implies when this tool is relevant, though it does not explicitly name alternatives like site_select or state when not to use it.
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, the description carries the full burden of behavioral disclosure. It explicitly reveals the stateful side effect: all later queries switch to this site. It also discloses that partial names are acceptable, which is useful behavioral information. It does not mention error cases like multiple matches, but for a simple selection tool this is a minor gap.
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 with zero wasted words. The core action is front-loaded, followed by input flexibility rules and the state-changing consequence. Every sentence earns its place.
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?
For a single-parameter, no-output-schema selection tool, this description is fully adequate. It tells the agent what the tool does, how to provide the argument, and what side effect to expect. No critical information is missing.
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?
The schema already documents the single parameter as '사이트 이름 일부 또는 siteId' with 100% coverage, so baseline is 3. The description adds real value by giving a concrete example ('부산시설공단') and explicitly confirming that only a partial name suffices, which helps an agent understand the accepted input format more concretely.
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 ('바꾼다' - changes) and clear resource ('조회 대상 사이트' - the site being queried), making the tool's purpose unmistakable. It also clarifies the input options (partial name or exact siteId), which distinguishes it from sibling tools like site_list that only list sites, and from data query tools that use the selected site.
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 states that all subsequent queries will be based on this site, which clearly implies this tool should be invoked before running queries when the target site needs to be changed. It stops short of explicitly naming alternatives or stating when not to use it, but the context is clear enough for an agent to decide.
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

arimair-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![arimair-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/arim-science/arimair-mcp/badges/card.svg)](https://glama.ai/mcp/servers/arim-science/arimair-mcp)

Score Badge

Copy to your README.md:

[![arimair-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/arim-science/arimair-mcp/badges/score.svg)](https://glama.ai/mcp/servers/arim-science/arimair-mcp)

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/arim-science/arimair-mcp'

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