ovf-data-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Each tool targets a distinct purpose: dataset discovery, schema inspection, aggregation, soil-depth comparison, drought declarations, measurement-type metadata, station lookup, proximity search, raw observations, and coverage inspection. The only mild overlap is find_stations vs nearest_stations, but the descriptions (registry/name search vs geographic proximity) make the distinction fairly clear.
Naming Consistency2/5
The naming is inconsistent, mixing verb-based names (discover_datasets, describe_dataset, aggregate_observations, compare_soil_depths, list_measurement_types, find_stations, get_observations, inspect_coverage) with noun-phrase names (water_shortage_districts, nearest_stations). Some use verb_noun (find_stations, describe_dataset), others drop the leading verb (nearest_stations, water_shortage_districts). The 'describe_dataset' vs 'discover_datasets' singular/plural mismatch also adds inconsistency.
Tool Count5/5
Ten tools is a well-scoped surface for an observational water data domain, covering discovery, metadata, querying, and analysis. Each tool serves a distinct function and none feels like filler; the count is squarely in the ideal 3-15 range.
Completeness4/5
The surface covers discovery, metadata inspection, raw observation retrieval, aggregation, soil-depth comparison, station lookup, proximity search, and drought declarations. Minor gaps include no direct update/delete (not applicable to a read-oriented data service) and possibly no explicit download/export tool, but the core observational querying workflow appears complete.
Average 2.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 57 commits in the last 12 weeks
- Last stable release on July 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'server-side' computing but doesn't disclose rate limits, required auth, result limits, or what the aggregated output structure looks like. With zero annotation coverage for a computation-heavy tool, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste, listing the purpose and bucket options concisely. However, this conciseness sacrifices useful detail that the tool needs — the tradeoff favors brevity over informativeness given the 9 parameters.
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 9 parameters, 0% schema coverage, and a complex aggregation operation, yet the description explains almost nothing about parameter interplay (interval vs operation vs metric), what statistics can be computed, or how the output schema relates. Despite having an output schema, the input side is severely under-documented for a tool this complex.
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 description coverage is 0%, and the description adds no parameter-level meaning. There are 9 parameters (3 required), including operation (default 'max'), interval, metric, data_type — none of which are explained. The description names the bucket types but never maps them to the 'interval' parameter or explains what operation/others control. The description fails to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Aggregate observations server-side over daily, ten-day, monthly, or yearly buckets' — a clear verb (aggregate) + resource (observations) + bucket sizes. However, it does not distinguish itself from sibling get_observations, which likely returns raw observations; the relationship between the two is left to inference.
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 says aggregation is over various buckets but gives no guidance on when to choose this tool versus get_observations, or what 'server-side' aggregation means operationally for the agent. No explicit when/when-not guidance or alternatives are named. The aggregation vs raw distinction is implied but not stated.
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 disclosure burden. It lists what fields are inspected (schema, CRS, limits, provenance) which adds some behavioral context, but doesn't disclose whether this is a read-only operation, what happens with missing/unavailable metadata, or any auth/permission requirements.
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, efficient sentence that fronts the core purpose and enumerates the key inspection areas compactly. No wasted words or filler.
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 2 parameters, no annotations, 0% schema description coverage, and the description is short. The tool inspects data with multiple semantic dimensions (schema, CRS, limits, provenance), and the interaction between dataset_id and layer_id is not fully explained. An output schema exists which offsets some return-value explanation need, but the description remains thin for a tool with this inspection scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The description explains dataset_id's role ('inspect one dataset or layer') at a high level, and layer_id's role is implied by 'or layer', but neither parameter's exact format, constraints, or interaction is clarified. It adds some meaning but not enough to bridge a 0% coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Inspect one dataset or layer') and lists what it covers (schema, CRS, limits, provenance), which is clear. However, with 9 sibling tools including discover_datasets and inspect_coverage, it doesn't explicitly distinguish itself from these related inspection/discovery 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?
No explicit when-to-use or when-not-to-use guidance is given. The description implies it's for inspecting dataset metadata, but doesn't contrast with siblings like discover_datasets (discovery vs. inspection) or inspect_coverage (which may overlap in purpose). The differentiation gap is notable given the tool count.
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 full burden of behavioral disclosure. The description only states the operation ('compare aligned series') but doesn't disclose what 'aligned' means, whether this is a read-only aggregation operation, what happens with missing depths, how multi-depth data is combined, or any performance considerations. The tool likely produces a derived/computed output, but no behavioral detail is disclosed.
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 concise sentence with no wasted words. It's appropriately short given that it offers little content. However, conciseness at the cost of completeness means the brevity isn't earned—there's substantial missing information that could have been compressed into a still-compact but more complete description.
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 an output schema and 8 parameters (3 required), the description addresses none of the tool's complexity. It doesn't explain what the comparison produces, how depths map to series, what 'aligned' means operationally, what operations are available, or how the metric/data_type/interval parameters behave. Even with the output schema present, the description is inadequate for an 8-parameter comparison tool.
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 description coverage is 0%, so the description carries the full burden of explaining parameters. With 8 parameters including metric, interval, data_type, depths_cm, and operation, the description provides zero elaboration on any of them. The term 'aligned' hints at alignment logic but doesn't explain the operation parameter (avg) or how depths_cm filtering works, metric selection, or data_type semantics. This is a significant gap.
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 'Compare aligned soil-moisture or temperature series across sensor depths' clearly identifies the verb (compare), resource (soil series), and scope (across sensor depths). It distinguishes from siblings like get_observations (fetch raw series) and aggregate_observations (aggregate observations), though it doesn't explicitly name alternatives. The purpose is specific to depth-based comparison, differentiating it from other observation 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?
No when-to-use guidance is provided. The description doesn't say when to use this over get_observations, aggregate_observations, or describe_dataset. It implies a comparison use case but gives no exclusions or alternative tool references. Given 9 siblings, the lack of guidance is a clear gap.
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. The phrase 'results are bounded' is vague—it hints at pagination or a limit but doesn't clarify what bounds apply, the default behavior, or whether the limit parameter controls it. It doesn't disclose the return format, ordering, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with minimal waste. It's front-loaded with the core purpose. However, it is over-terse; the brevity comes at the cost of needed content rather than trimming redundancy, which slightly undermines this as 'appropriately sized.'
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 an output schema and only 2 optional parameters (simple tool), the description is under-specified. No annotations and 0% schema coverage mean it should carry substantial informational weight, but it doesn't. While the output schema covers return values, the tool's filtering/list semantics remain opaque.
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 compensate for both parameters (limit and query), but it mentions neither. The agent doesn't learn what 'query' expects (catalogue identifier format?) or how 'limit' caps results. The schema gives only types and defaults with no meaning, and the description adds nothing about either parameter.
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+resource (find public water datasets) and a clear scoping mechanism (by catalogue identifier). It distinguishes from siblings like get_observations and find_stations by focusing on dataset discovery rather than data retrieval. However, it doesn't explicitly explain how it differs from describe_dataset, which could cause some ambiguity among dataset-focused siblings.
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. No exclusions, no when-not-to-use, and no mention of alternatives like describe_dataset or find_stations. The description implies a search-or-listing use case but provides no explicit context for the agent to decide between this and sibling 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 carries the full burden. 'Resolve a station' implies it maps/resolves identifiers, and 'reports documented temporal coverage' describes output, but it does not mention whether this is a read-only operation, any rate limits, or what happens with unresolvable stations. No schema values (defaults like metric and data_type) are explained in behavioral terms.
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 concise sentence with no wasted words. It front-loads the core action and purpose. However, it is slightly under-specified—conciseness here borders on sparse rather than optimally economical given the amount of missing behavioral detail.
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?
While an output schema exists (mitigating the need to describe return values), the tool has 3 parameters with 0% schema coverage, no annotations, and a purpose that is central to workflow sequencing ('before querying'). The description should clarify what 'temporal coverage' reporting entails, how metric and data_type influence it, and what distinguishes this from discover_datasets/describe_dataset. It leaves significant gaps.
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 description coverage is 0%, and the description mentions the station parameter implicitly (resolving a station) but provides no semantics for 'metric' (default water-level) or 'data_type' (default operational). The description does not explain what these parameters mean or how they affect the coverage report. With zero schema coverage and no param description, compensation is absent.
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 ('Resolve a station and report documented temporal coverage before querying'). This clearly indicates the tool resolves a station identifier and reports its temporal coverage. It distinguishes reasonably from siblings like describe_dataset and discover_datasets, though it doesn't 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before querying' implies it should be used as a prerequisite to data queries, but this is subtle and not explicit. It does not state when to use this vs alternatives like describe_dataset or discover_datasets, nor does it specify exclusions or prerequisites beyond the implied sequencing.
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 discloses the 7-day limit, which is useful, but doesn't describe pagination behavior, rate limiting, what happens with large intervals, whether data is ordered, or the nature of the raw observations returned. With zero annotation coverage and an output schema present, more behavioral context would be valuable.
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 brief and front-loaded with the core purpose in the first sentence. The second line about include_quality is relevant but could be clearer about whether it's optional or default behavior. Slightly minimal but no wasted words.
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 9 parameters at 0% schema coverage, no annotations, and multiple sibling tools with overlapping functionality (aggregate_observations, compare_soil_depths), the description is significantly under-specified. The output schema exists but doesn't reduce the need for parameter guidance. A moderate-complexity tool like this needs more than two short lines.
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 description coverage is 0%, so the description must compensate for 9 parameters. Only include_quality is explained ('add upstream quality codes and labels per observation'). The meaning of data_ext, depth_cm, data_type, metric, limit, and the date formats of start/end are all undocumented in both schema and description.
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 'Get raw observations for an explicit interval of at most 7 days,' which is a specific verb+resource+scope. It distinguishes from siblings like aggregate_observations (raw vs aggregated) and inspect_coverage/inspect functionality. However, it doesn't explicitly differentiate from all siblings, and 'raw observations' could be slightly clearer about what kind of data is returned.
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 7-day max interval is a useful usage constraint, but there's no guidance on when to use this vs. aggregate_observations or other sibling tools. No exclusions or alternatives are named. The 'explicit interval' phrasing implies it requires explicit start/end dates, but this is not fully developed.
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 full burden for behavioral disclosure. It does not state what the response contains (station metadata, distances?), whether results are sorted by distance, how many results max (limit default is in schema but not described), or any rate limits or access constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the network value explanations are oddly embedded in the description rather than the schema. The opening line is good and front-loaded, but the trailing network bullet feels like it belongs in the schema, making the description slightly mis-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?
For a geospatial lookup tool with 5 parameters and 0% schema coverage, the description does not fully compensate. It explains the network parameter but leaves latitude/longitude format, metric, and limit semantics unexplained. Having an output schema helps, but the input semantics are not complete.
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%, so none of the 5 parameters are described in the schema, but the description does explain the network values (surface, wells, deep-wells, precipitation) which is genuinely useful. However, latitude, longitude, limit, and metric parameters have no explanation in either the schema or description.
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 it finds public gauges nearest given coordinates, which is specific and clear. The network parameter explanation (surface, wells, deep-wells, precipitation) helps differentiate from siblings like get_observations and find_stations, though it doesn't 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 implies usage (find nearest stations to a coordinate) but gives no explicit guidance on when to prefer this over siblings like find_stations or inspect_coverage. No when/when-not exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It doesn't mention what the output looks like, whether this is a safe read operation, any pagination or result limits, or what 'find' means in terms of matching behavior (exact vs fuzzy). The network enum listing helps somewhat, but the tool's behavior around the query parameter and how filters combine is left unexplained. For a search tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the key purpose in the first line. The network enumeration is useful and efficiently formatted. It doesn't waste space, though it could have used the structure better by explaining metric and query semantics in the remaining space.
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 has 6 parameters, no annotations, and no schema description coverage — a moderate complexity tool where the description needs to compensate. The description covers the network field well and hints at search dimensions but leaves metric entirely unexplained and gives no sense of result format. With an output schema present, return values don't need detailing, which helps, but the missing metric semantics and lack of behavioral guidance on filtering combination leave meaningful gaps for an agent to navigate this multi-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all 6 parameters are undocumented in the schema. The description adds meaning to network by enumerating its valid values, and implicitly explains query, watercourse, and municipality search filters. However, the 'metric' and 'limit' parameters are not explained at all in the description, and there's no clarity on what the metric filter does or how it relates to network. This partial coverage earns a middle score.
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 finds gauges by registry ID, name, watercourse, or municipality. The verb 'find' plus the resource 'gauges' and the search criteria provide good purpose clarity. It doesn't explicitly distinguish from siblings like nearest_stations, but it names the search dimensions clearly enough to establish its distinct role as a general lookup tool.
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 explains what the tool does and lists the search dimensions, but provides no when-to-use versus alternatives guidance. Given siblings include nearest_stations and get_observations, guidance on when to choose this over those alternatives would be valuable. The network field enumeration offers some implicit selection context, but there's no explicit statement about when this tool is the right choice.
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 explains the key semantics: these are official administrative grades with a defined grade_code mapping (720=none to 723=most severe). It doesn't disclose pagination behavior, filtering defaults, or response format, but it does carry its share of the burden for explaining the domain meaning.
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 clear front-loading of the core purpose in the first line, followed by a useful one-sentence clarification about the administrative nature and grade_code mapping. Efficient and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with an output schema present and only 3 simple parameters, the description provides reasonable domain context but leaves gaps: it doesn't explain the limit or directorate parameters, and doesn't clarify default filtering behavior. It is adequate but not thorough for a tool with zero annotation coverage.
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 description coverage is 0%, so the description must compensate by explaining parameters. It does explain the meaning of grade_code values (720-723) and the 'district' output context, but it does not explain what 'limit' controls or what the 'directorate' filter does or accepts as values. Two of three parameters remain semantically undocumented.
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+resource ('List officially declared water-shortage (drought) grades per district') that clearly distinguishes it from sibling tools. It clarifies this is about administrative drought declarations, not measurements, which distinguishes it well from measurement-focused siblings like get_observations and aggregate_observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clarifies these are administrative declarations 'not measurements,' providing some context for when to use this tool vs measurement tools. However, it doesn't explicitly state when to choose this over alternatives or name any specific alternative tool for similar filtering scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. This is clearly a read-only, non-destructive lookup tool, and the description appropriately reflects that. However, it doesn't describe pagination, ordering, or whether the full code set fits in one response, which would be useful behavioral context for a reference-list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that lists the exact content categories (codes, units, ranges, data-type codes). It's efficient with no wasted words, though slightly more context about intended use could enrich it.
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?
The tool has no parameters and an output schema (which presumably documents the fields), so the description's job is limited to establishing the purpose and content scope. It does that adequately. Given the low complexity (0 params, no nested objects) and presence of output schema, the description is reasonably complete for this 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 tool has 0 parameters and schema description coverage is 100% (trivially, since there are no parameters). With no parameters to explain, the baseline of 4 is appropriate; the description doesn't need to add parameter semantics when none exist.
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 lists 'authoritative metric codes, units, valid ranges, and data-type codes.' It specifies the verb (list), the resource (measurement types/metrics), and the scope (authoritative codes with units/ranges). It distinguishes reasonably from siblings like describe_dataset and aggregate_observations, though it doesn't name them explicitly.
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 this tool is a reference/lookup for measurement units and codes, but does not explicitly state when an agent should use it versus alternatives (e.g., describe_dataset). The context of being a dictionary/reference tool is clear but no explicit when/when-not guidance is given.
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:

[![ovf-data-mcp MCP server](https://glama.ai/mcp/servers/kalcifield/ovf-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kalcifield/ovf-data-mcp)

Score Badge

Copy to your README.md:

[![ovf-data-mcp MCP server](https://glama.ai/mcp/servers/kalcifield/ovf-data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kalcifield/ovf-data-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/kalcifield/ovf-data-mcp'

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