mcp-test
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_temperatureA | Get the current air temperature for a city, by name. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of overlapping purposes or misselection. The single get_temperature action is completely unambiguous.
The one tool uses a clear get_ + noun naming convention. There are no competing conventions or mixed styles to create inconsistency.
A single tool is on the 'too few' end of the scale, making the server feel like a minimal stub rather than a useful service. Unless the intended purpose is literally only a current temperature lookup, this is insufficient.
For a temperature/weather-related domain, the surface lacks related operations such as unit selection, forecast, geocoding, or validation. The single lookup creates a dead end and leaves obvious gaps for broader temperature use cases.