SHEARLINE

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool has a distinct purpose: warnings, radar products, environment, radar metadata, outlook, reports, and a composite brief. There is no overlap, and an agent can clearly differentiate them.
Naming Consistency5/5
All tools follow a consistent 'get_' prefix with snake_case noun phrases (e.g., get_active_warnings, get_mrms_severe). No mixing of styles or irregular verbs.
Tool Count5/5
Seven tools is well-suited for a severe weather analysis server, covering warnings, radar, environment, outlook, reports, and a composite without being too few or excessive.
Completeness4/5
The tool set covers the primary data sources for severe weather threat assessment. Minor gaps like radar imagery or satellite data exist, but the composite tool integrates the available tools effectively.
Average 4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on June 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that reports are 'local' (spotter/official) and 'normalized', with temporal (past N hours) and spatial (radius_km) scope. However, it does not mention data limitations (e.g., only CONUS, potential latency, or that reports may be sparse). Adequate but not exhaustive.
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, front-loaded with the tool's purpose and key constraints. Every word is informative; no fluff 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?
Given the presence of an output schema, the description need not fully detail return values, but it already lists key output fields. However, it omits details on result ordering, maximum results, or handling of empty responses. For a tool returning many reports, this could hamper effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It mentions 'within radius_km' and 'over the past N hours', which map to radius_km and hours parameters, but does not clarify lat/lon format, units (expected decimal degrees), valid ranges, or the default values. The description adds some value but is insufficient for comprehensive parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'Local Storm Reports' (spotter/official reports) near a CONUS point, with specific types (tornado, hail, wind, flood). It distinguishes from sibling tools like get_active_warnings and get_radar_snapshot by focusing on historical reports rather than warnings or radar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining storm reports in an area, but lacks explicit guidance on when to use this tool versus siblings, such as when to prefer get_mrms_severe or get_active_warnings. No when-not-to-use or prerequisites are stated.
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. It describes the return data (categorical risk, probabilities, flags) but does not disclose behavioral traits like idempotency, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description covers the return fields adequately. However, it lacks parameter details, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only mentions 'day 1, 2, or 3' without explaining lat/lon format, range, or the day parameter's default and allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns SPC convective outlook at a CONUS point for days 1-3, specifying categorical risk, hazard probabilities, and flags. It distinguishes from sibling tools like get_active_warnings and get_radar_snapshot by focusing on forecast outlooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining outlook data but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that GLM detects total lightning from GOES-East with 20-40 s latency, and it explains the output composition. Without annotations, this provides reasonable transparency, though it could detail data freshness limitations or edge cases.
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 mostly concise, with two sentences that front-load the purpose. The first sentence is somewhat long but packs necessary information. Minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers the tool's functionality: output fields, source, latency. It provides enough context for an AI agent to use the tool correctly, though parameter details are sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning. It mentions 'radius_km' and 'minutes' as time window parameters but does not clarify lat/lon or provide format details. The default values are in schema but not explained in description.
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 GOES GLM total-lightning activity near a CONUS point, listing specific output fields such as flash count, rate, nearest strike, and a tiered safety interpretation. It is distinct from sibling tools, which focus on other weather phenomena.
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 real-time use with 'recent window' but does not explicitly state when to use this tool versus alternatives like get_threat_brief. No exclusion criteria or context for selection are provided.
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, yet the description discloses important behavioral details: it downloads the latest RAP data, uses MetPy for computation, and notes that the first call may take several seconds. This compensates well for the lack of 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 paragraph that efficiently conveys the tool's purpose and output. It is appropriately sized, though could be broken into separate sentences for readability. No extraneous text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (computing many parameters) and the presence of an output schema, the description thoroughly lists all computed quantities and mentions interpretation behavior. This fully informs an agent of what to expect without needing to inspect the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (lat, lon) with 0% schema description coverage. The description does not explain their meaning, format, or valid ranges. As a basic geographic coordinate, the purpose is obvious, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes severe-weather environment parameters from RAP analysis at a CONUS point, listing many specific outputs (MLCAPE, shear, etc.). It distinguishes from sibling tools like get_active_warnings or get_radar_snapshot by focusing on atmospheric profile analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for severe weather analysis but does not explicitly state when to use this tool versus alternatives like get_spc_outlook. No guidance on prerequisites or when not to use is given.
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 exist, so the description carries full burden. It transparently discloses the types of warnings, what data is returned (tags, storm motion, expiration, geometry, point-in-polygon check), and that watches are listed separately. However, it omits rate limits, authentication requirements, or any side effects (though likely read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three compact sentences that front-load the core purpose, then list details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple warning types, return fields, geometry), no annotations, and 0% schema coverage, the description is fairly complete. It covers what warnings are included, key return fields, and the point-in-polygon check. The output schema likely provides remaining details. Minor gap: no mention of radius_km bounds or CONUS-specific constraints.
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 0% (no parameter descriptions). The description adds context by mentioning 'CONUS point' for lat/lon and 'within radius_km' for radius_km, but does not specify units, valid ranges, or format. It compensates partially but not fully for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns active NWS severe-weather warning polygons near a CONUS point, lists specific warning types (tornado, severe thunderstorm, flash flood), and details the returned data (tags, storm motion, expiration, geometry, point-in-polygon). This distinguishes it from sibling tools by focusing on active warnings vs other severe weather products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining active warnings near a location but provides no explicit guidance on when to use this tool versus alternatives like get_mrms_severe or get_threat_brief. No exclusions or context-dependent advice is given.
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 full burden. It discloses that the tool runs multiple products concurrently, that the first call may take ~10 seconds due to RAP profile download, and describes the output structure. This provides good transparency about behavior and performance.
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 concise, well-structured paragraph of four sentences. The first sentence captures the primary purpose, and each subsequent sentence adds necessary detail without redundancy. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (composite of multiple data sources) and minimal schema, the description provides a good overview of the output. It mentions all key output components and notes the latency behavior. The presence of an output schema reduces the need for detailed return value explanations. Minor gaps in error or boundary handling, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds context that lat/lon are for a CONUS point and are used as the location for the brief. This provides basic meaning beyond the schema but lacks details like coordinate bounds or format expectations.
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's purpose: it is a 'Composite severe-weather threat brief for a CONUS point' that runs multiple data sources concurrently and synthesizes them. It distinguishes itself from sibling tools like get_active_warnings by being a composite rather than a single source.
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 should be used for a comprehensive threat overview, but it does not explicitly contrast it with individual sibling tools or state when to use one over the other. Some guidance on use cases or when not to use it would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it downloads/decodes four forecast hours, notes ~15-20 sec initial call, and explains the trajectory interpretation. This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence stating the core purpose. It includes necessary details without excessive verbosity, though slight restructuring could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and presence of an output schema, the description adequately covers return values (MLCAPE, shear, SRH, etc.) and latency. Missing error handling or authentication details, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not elaborate on lat/lon parameters beyond implying a CONUS point. No valid ranges, format, or defaults are given, so the description adds minimal value for parameter usage.
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 returns a RAP forecast-environment trend for a CONUS point, differentiating it from get_point_environment which is 'now'. It lists specific variables and mentions trajectory interpretation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contrasts with get_point_environment, indicating when to use this tool for forecast trends rather than current conditions. However, it does not explicitly mention when not to use it or provide alternatives among the nine sibling 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?
No annotations are provided, so the description carries the full burden. It transparently discloses the download size (~5-15 MB) and expected delay on first call, along with the specific metadata fields returned. It does not mention error cases or permissions, but for a read-only metadata tool these are less critical.
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, front-loaded with the main purpose, and efficiently provides details on what is returned and a performance note. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the return values are covered. The description adequately explains the tool's scope, data included, and a performance caveat. It does not address potential errors like missing radar coverage, but overall is sufficiently complete for a simple metadata retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (lat, lon) with 0% description coverage. The description does not explain these parameters further, but they are standard coordinates and their purpose is clear from context. Minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest NEXRAD Level 2 volume metadata from the nearest radar, specifying it is metadata only and listing the data fields. It distinguishes from sibling tools like get_active_warnings or get_mrms_severe by focusing on radar metadata.
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 informs that the tool returns metadata only (no imagery) and mentions the download size and time cost. This indirectly guides users to not use it if they need imagery, but lacks explicit comparison to alternative 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?
Without annotations, the description effectively discloses key behaviors: it samples within radius_km, returns max values over the last hour, and includes valid time and distance/bearing. However, it omits details like authentication needs or whether data is cached, though the core behavior is well-communicated.
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 exceptionally concise, consisting of two dense sentences that front-load the core purpose and then list specific products with details. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple severe weather products), the description thoroughly lists what is returned (MESH, shear, VIL, reflectivity) with units and time windows. The presence of an output schema means return format details are covered externally, making this description complete 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?
Despite 0% schema description coverage, the main description adds meaning by stating the tool retrieves data 'near a CONUS point' and uses radius_km for sampling. This clarifies that lat/lon define the center point. However, it does not specify constraints like valid ranges for lat/lon or radius_km, leaving some ambiguity.
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 returns MRMS radar-derived severe weather products near a CONUS point, listing specific products (MESH, shear, VIL, reflectivity). This distinctively differentiates it from siblings like get_active_warnings or get_radar_snapshot, which cover different data. The verb 'get' is implied, and the resource is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining severe weather parameters at a point but provides no explicit guidance on when to use this tool versus siblings. It does not mention prerequisites, exclusions, or alternatives, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data source (preliminary NWS/spotter via Iowa Environmental Mesonet), coverage start (~2005), preliminary nature vs. final NCEI record, and output structure (normalized reports with summary).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and organized logically: purpose, specifics, output, caveats, alternatives. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (reducing need to describe returns), the description sufficiently covers usage, parameters, data caveats, and alternatives. It is complete for agent decision-making.
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 0%, but description adds meaning for date format (YYYY-MM-DD) and output structure related to parameters. However, it does not explain lat/lon format or radius_km semantics beyond default, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves local storm reports for a past date near a CONUS point, specifying it answers about hail, wind, or tornado. It distinguishes from the sibling tool get_storm_reports, which is for current situations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (past dates) and when not to (current situation), directing to the alternative get_storm_reports. This is clear guidance for agent selection.
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

Copy to your README.md:

[![shearline MCP server](https://glama.ai/mcp/servers/lostnumber07/shearline/badges/card.svg)](https://glama.ai/mcp/servers/lostnumber07/shearline)

Score Badge

Copy to your README.md:

[![shearline MCP server](https://glama.ai/mcp/servers/lostnumber07/shearline/badges/score.svg)](https://glama.ai/mcp/servers/lostnumber07/shearline)

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/lostnumber07/shearline'

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