Skip to main content
Glama
srpp011

dailymeteo-mcp

by srpp011

DailyMeteo account and credits

account_status
Read-only

Retrieve plan status and remaining API and bulk credits for daily point/area data and point history before querying weather data.

Instructions

Plan and remaining credits: API credits (daily point and area data) and bulk credits (point history).

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful domain context by distinguishing API credits (daily point/area data) from bulk credits (point history), but says nothing about authentication requirements, whether counts update in real time, or what a depleted balance implies for subsequent calls.

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 compact sentence with the core concept ('Plan and remaining credits') front-loaded and the two credit categories immediately clarified. No wasted text, though the fragment style ('Plan and remaining credits:') is slightly telegraphic.

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 no input parameters and no output schema, the description carries the burden of explaining return content. It identifies the fields conceptually (plan, API credits, bulk credits) but gives no sense of units, structure, or how to interpret a low balance against the request_* tools.

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 baseline of 4 applies; there is nothing for the description to disambiguate 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 names the resource ('Plan and remaining credits') and enumerates the two credit pools it reports, so an agent knows exactly what information it yields. It lacks an explicit verb, but no sibling tool covers account/credit data, so differentiation is implicit and strong.

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 statement of when to call it or in what sequence relative to the request/download tools. An agent must infer that this is a pre-flight credit check rather than being told so.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.