How do I use Rasdaman MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Rasdaman MCP Server Show me the dimensions and metadata for the 'Sentinel2_10m' coverage" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Rasdaman MCP Server

Official

by rasdaman

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Rasdaman MCP Server

This tool enables users to interact with rasdaman in a natural language context. By exposing rasdaman functionality as tools via the MCP protocol, an LLM can query the database to answer questions like:

"What datacubes are available?"
"What are the dimensions of the 'Sentinel2_10m' coverage?"
"Create an NDVI image for June 12, 2025."

The MCP server translates these tool calls into actual WCS/WCPS queries that rasdaman can understand and then returns the results to the LLM.

Installation

pip install rasdaman-mcp

Related MCP server: mcp-geo-server

Usage

First the connection from the MCP server to rasdaman needs to be configured, either through environment variables:

RASDAMAN_URL: URL for the rasdaman server
RASDAMAN_USERNAME: Username for authentication
RASDAMAN_PASSWORD: Password for authentication

or command-line arguments to the rasdaman-mcp tool:

--rasdaman-url: URL for the rasdaman server (default RASDAMAN_URL env variable or http://localhost:8080/rasdaman/ows).
--username: Username for authentication (default RASDAMAN_USERNAME env variable or rasguest).
--password: Sets the password for authentication (default RASDAMAN_PASSWORD env variable or rasguest).

Then the MCP is ready to be used with an AI agent tool, in one of two modes: stdio (default) or http.

`stdio` Mode

Used for direct integration with clients that take over managing the server process and communicate with it through standard input/output. Generally in your AI tool you need to specify the command to run rasdaman-mcp:

rasdaman-mcp --username rasguest --password rasguest --rasdaman-url "..."

Example for enabling it in gemini-cli:

gemini mcp add rasdaman-mcp "rasdaman-mcp --username rasguest --password rasguest"

Benefits:

Simplicity: No need to manage a separate server process or ports.
Seamless Integration: Tools are transparently made available to the LLM within the client environment.

`http` Mode

This mode starts a standalone Web server listening on a specified host/port, e.g:

rasdaman-mcp --transport http --host 127.0.0.1 --port 8000 --rasdaman-url "..."

The MCP server URL to be configured in your AI agent would be http://127.0.0.1:8000/mcp with transport streamable-http. For example, for Mistral Vibe extend the config.toml with a section like this:

[[mcp_servers]]
name = "rasdaman-mcp"
transport = "streamable-http"
url = "http://127.0.0.1:8000/mcp/"

Benefits:

Scalability: The MCP server can be containerized (e.g., with Docker) and deployed as a separate microservice.
Decoupling: Any client that can speak HTTP (e.g., curl, Python scripts, web apps, other LLM clients) can interact with the tools.
Testing: Allows for direct API testing and debugging, independent of an LLM client.

AI agents

Once an AI agent is configured with access to rasdaman-mcp, it becomes capable of using several tools:

list coverages in the configured rasdaman
get the details of a particular coverage
execute processing/analytics queries based on a description in natural language

Examples

The following examples demonstrate the interaction with an AI agent using the rasdaman MCP server.

Listing Coverages

Describing a Coverage

Executing a Query

Query Result Visualization

Natural Language Query Suggestion

Development

Setup

Clone the git repository:

git clone https://github.com/rasdaman/rasdaman-mcp.git
cd rasdaman-mcp/

Create a virtual environment (if you don't have one):
```
uv venv
```
Activate the virtual environment:
```
source .venv/bin/activate
```
Install from source:
```
uv pip install -e .
```

Core Components

Main Application (main.py): This script initializes the FastMCP application. It handles command-line arguments for transport selection, rasdaman URL, username, and password. It then instantiates the RasdamanActions class and decorates its methods to expose them as tools.
RasdamanActions Class (rasdaman_actions.py): Encapsulates all interaction with the rasdaman WCS/WCPS endpoints. It is initialized with the server URL and credentials, and its methods contain the logic for listing coverages, describing them, and executing queries.
WCPS crash course (wcps_crash_course.py): A short summary of the syntax of WCPS, allowing LLMs to generate more accurate queries.

Defined Tools

The following methods are exposed as tools:

list_coverages(): Lists all available datacubes.
describe_coverage(coverage_id): Retrieves metadata for a specific datacube.
wcps_query_crash_course(): Returns a crash course on WCPS syntax with examples and best practices.
execute_wcps_query(wcps_query): Executes a raw WCPS query and returns a result either directly as a string (scalars or small json), or as a filepath.

Documentation

To build the documentation:

# install dependencies
uv pip install '.[docs]'

sphinx-build docs docs/_build

You can then open docs/_build/index.html in the browser.

Automated Tests

To run the tests:

# install dependencies
uv pip install '.[tests]'

pytest

Manual Testing

Interacting with the standalone HTTP server manually requires a specific 3-step process using curl. The fastmcp protocol is stateful and requires a session to be explicitly initialized.

First, send an initialize request. This will return a 200 OK response and, most importantly, a session ID in the mcp-session-id response header (needed in the next steps).

curl -i -X POST \
-H "Accept: text/event-stream, application/json" \
-H "Content-Type: application/json" \
-d '{
      "jsonrpc": "2.0",
      "method": "initialize",
      "params": {
        "protocolVersion": "2024-11-05",
        "capabilities": {},
        "clientInfo": { "name": "curl-client", "version": "1.0.0" }
      },
      "id": 1
    }' \
"http://127.0.0.1:8000/mcp"

Next, send a notification to the server to confirm the session is ready. Use the session ID from Step 1 in the mcp-session-id header. This request will not produce a body in the response.

SESSION_ID="<YOUR_SESSION_ID>"

curl -X POST \
-H "Accept: text/event-stream, application/json" \
-H "Content-Type: application/json" \
-H "Mcp-Session-Id: $SESSION_ID" \
-d '{
      "jsonrpc": "2.0",
      "method": "notifications/initialized"
    }' \
"http://127.0.0.1:8000/mcp"

Finally, you can call a tool using the tools/call method. The params object must contain the name of the tool and an arguments object with the parameters for that tool. The server will respond with the result of the tool call in a JSON-RPC response.

SESSION_ID="<YOUR_SESSION_ID>"

# Example: Calling the 'list_coverages' tool
curl -X POST \
-H "Accept: text/event-stream, application/json" \
-H "Content-Type: application/json" \
-H "Mcp-Session-Id: $SESSION_ID" \
-d '{
      "jsonrpc": "2.0",
      "method": "tools/call",
      "params": {
        "name": "list_coverages",
        "arguments": {}
      },
      "id": 2
    }' \
"http://127.0.0.1:8000/mcp"

Available Tools

6 tools

describe_coverageA

Retrieves structural metadata for a specific datacube (coverage).

ParametersJSON Schema

Name	Required	Description	Default
`coverage_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the disclosure burden. It does clearly indicate a read-only metadata retrieval with no data mutation, which is a useful behavioral signal, but it does not mention error behavior, required permissions, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short, front-loaded sentence with no redundancy. It states the action and target immediately.

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 one-parameter metadata retrieval with an output schema, the description covers the essential what and who. The main omission is guidance on obtaining a valid coverage_id, but the sibling tool list_coverages and the single required parameter make this inferable.

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 for the sole parameter coverage_id is 0%, so the description must compensate. It adds only that the parameter refers to a specific datacube, which largely restates the parameter name, and does not explain where valid IDs come from or what format they take.

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 action verb ('Retrieves') and a clear resource ('structural metadata for a specific datacube/coverage'). The word 'specific' distinguishes it from the sibling list_coverages, which enumerates coverages.

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 phrase 'specific datacube (coverage)' implies the tool is for looking up one known coverage, and sibling names like list_coverages suggest a prior listing step. However, it never explicitly states when to choose it over execute_wcps_query or that coverage_id should come from list_coverages.

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

execute_wcps_queryA

Executes a Web Coverage Processing Service (WCPS) query in rasdaman. Use this for spatio-temporal subsetting of datacubes, processing, aggregation, filtering.

Returns a structured dictionary indicating success, result_type, original query, the actual result value for scalar and small JSON or file path for large/binary results.

Important: Show the actual WCPS query and the result file path to the user.

ParametersJSON Schema

Name	Required	Description	Default
`wcps_query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

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 explicitly states the return structure ('structured dictionary indicating success, result_type, original query, the actual result value for scalar and small JSON or file path for large/binary results') and adds an important instruction to show the query and file path to the user. This goes beyond a bare execution description, though it does not mention side effects, error handling, or authentication requirements, which would strengthen it further.

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 four sentences with no filler. The purpose is front-loaded, followed by return type and a key practical instruction in bold. Every sentence earns its place, and the structure guides an agent efficiently.

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, explaining return details is not required, and the description already covers the return form. It addresses purpose, usage, and a critical user-facing requirement. It lacks explicit error descriptions or prerequisites, but these are implied by the 'success' field and the presence of documentation siblings, making it adequate for a single-parameter 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 single parameter wcps_query has 0% schema description coverage, so the description must compensate. It implies the query is a WCPS string and mentions capabilities like subsetting and aggregation, but it does not describe the query syntax, provide examples, or link to documentation. This is minimal added value over the parameter name itself; however, the parameter is a well-understood concept, and related doc tools exist, so a mid score 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 clearly states the verb 'Executes' and the resource 'WCPS query in rasdaman', and further specifies operations (spatio-temporal subsetting, processing, aggregation, filtering) that distinguish it from siblings like list_coverages and describe_coverage. An agent can immediately identify this as the query execution tool.

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 'Use this for spatio-temporal subsetting of datacubes, processing, aggregation, filtering', which provides clear context for when to invoke it. However, it does not mention exclusions, alternatives, or prerequisites (e.g., needing a pre-existing coverage), so it falls short of explicit when-not guidance.

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

list_coveragesA

Lists all available datacubes (coverages) in rasdaman.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and clearly conveys a non-mutating enumeration of all available coverages. It does not detail permission/availability semantics or scalability concerns, but these are minor for a zero-parameter list operation.

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 a clear verb and object. Every word earns its place, and there is no redundant or vague filler.

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 listing tool, the description is largely complete, and an output schema exists to document return values. It does not explicitly connect the list results to describe_coverage or querying, but that relationship is inferable from the sibling names.

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?

There are zero parameters and schema description coverage is 100%, so the empty input schema fully defines the call. The description adds no parameter information, but none is required; per rubric, 0 params earns a baseline of 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 states a specific verb ('Lists') on a clear resource ('all available datacubes/coverages in rasdaman'). It is distinguishable from siblings like describe_coverage, which targets a single coverage, and from query/documentation 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 implies the tool is used to discover available coverages, but it gives no explicit guidance on when to call it relative to describe_coverage, execute_wcps_query, or the documentation tools. It does not state exclusions or prerequisites.

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

wcps_doc_chaptersA

Lists the detailed WCPS documentation chapters, one per topic, each with a description of what it covers and when to fetch it. Use when the crash course is not detailed enough — pick the chapter matching your problem and fetch it with wcps_get_chapter(name). After a failed query, the 'common-errors' chapter maps error symptoms to fixes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

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 not explicitly mention that the tool is read-only, safe, or has any side effects. However, the nature of listing chapters implies no destructive behavior, but this is not confirmed.

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 with two sentences. The first sentence front-loads the main purpose, and the second adds valuable usage context. No unnecessary words.

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 tool with no parameters and an existing output schema, the description fully covers what the tool does and when to use it. It also mentions the related tool (wcps_get_chapter), completing the workflow context.

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?

There are no parameters (0), so schema coverage is 100%. The baseline for 0 parameters is 4. The description appropriately omits parameter details as none exist.

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: listing detailed WCPS documentation chapters. It uses the verb 'Lists' and specific resource 'WCPS documentation chapters', making the function unambiguous. Even without sibling tools, it is very clear.

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 this tool: 'Use when the crash course is not detailed enough' and after a failed query to consult the 'common-errors' chapter. This gives clear context and distinguishes its use case.

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

wcps_get_chapterA

Returns one full WCPS documentation chapter (markdown) by name, as listed by wcps_doc_chapters(). Example: wcps_get_chapter("switch-case").

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates a read-only retrieval returning markdown. However, it does not disclose behavior for invalid or unknown chapter names, nor any error handling or performance characteristics. For a simple getter, 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?

Two sentences with no filler. The core behavior is front-loaded, the source of valid parameter values is stated, and an example is included. 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?

The tool is simple and has an output schema, so the description does not need to detail return structure. It covers what the tool does, how to identify a chapter, and gives an example. Minor omissions like invalid-name behavior are acceptable given the simplicity.

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 0%, so the description must compensate. It does by explaining that 'name' refers to a chapter name from wcps_doc_chapters() and provides a concrete example ('switch-case'). This goes beyond the bare schema definition of 'name' as a string.

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 and resource: 'Returns one full WCPS documentation chapter (markdown) by name.' It also distinguishes itself from sibling tools by linking to wcps_doc_chapters() as the source of valid names, making its role clear relative to the chapter-listing sibling.

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 clearly implies when to use this tool: after listing available chapters via wcps_doc_chapters(), by providing a chapter name. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to determine this is the retrieval counterpart to wcps_doc_chapters.

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

wcps_query_crash_courseA

Returns a crash course on writing WCPS queries: learn the basic syntax, common operations, and best practices for WCPS queries. It's recommended to check this before executing queries.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden. It states the tool returns educational content rather than executing queries, making side effects clearly absent. It could more explicitly say 'does not run queries,' but the safety profile is evident from the wording.

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 tightly written sentences: the first explains what is returned, the second explains when to use it. No filler or redundant phrasing.

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, no-parameter informational tool with an output schema, the description provides the essential purpose and recommendation. It could name sibling tools like wcps_doc_chapters to avoid overlap, but the crash-course framing already distinguishes it well enough.

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 an empty schema, so there are no parameter semantics to document. The description adds no parameter detail, which is appropriate because no parameters exist.

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 concrete deliverable ('a crash course on writing WCPS queries') and enumerates its contents (basic syntax, common operations, best practices). This makes the tool's role clear and distinguishes it from execution-focused execute_wcps_query and chapter-level documentation siblings.

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 explicit timing guidance: 'recommended to check this before executing queries.' It does not name alternatives or exclusion cases, but for a zero-parameter informational tool the when-to-use context is sufficient for an agent to route correctly.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.4.5Aug 26, 2026
- Addeddescribe_coverage
- Addedexecute_wcps_query
- Addedlist_coverages
- Addedwcps_get_chapter
- Addedwcps_query_crash_course
5 tool updatesv0.4.0Jul 26, 2026
- Removeddescribe_coverage
- Removedexecute_wcps_query
- Removedlist_coverages
- Addedwcps_doc_chapters
- Removedwcps_query_crash_course
4 tool updatesv0.3.0Jun 26, 2026
- Changeddescribe_coverage2 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - removedOutput schema / description
```
Removed value: -"Generic wrapper for non-object return types."
```
- Changedexecute_wcps_query1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedlist_coverages4 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - removedOutput schema / description
```
Removed value: -"Generic wrapper for non-object return types."
```
  - removedOutput schema / properties / result / items
```
Removed value: -{
-  "type": "string"
-}
```
  - changedOutput schema / properties / result / type
```
Previous value: -"array"New value: +"string"
```
- Changedwcps_query_crash_course2 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - removedOutput schema / description
```
Removed value: -"Generic wrapper for non-object return types."
```
4 tool updatesv0.2.1Apr 30, 2026
- Addeddescribe_coverage
- Addedexecute_wcps_query
- Addedlist_coverages
- Addedwcps_query_crash_course
4 tool updatesv0.2.0Apr 30, 2026
- Removeddescribe_coverage
- Removedexecute_wcps_query
- Removedlist_coverages
- Removedwcps_query_crash_course
4 tool updatesv0.1.0Feb 26, 2026
- First observeddescribe_coverage
- First observedexecute_wcps_query
- First observedlist_coverages
- First observedwcps_query_crash_course

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-08-26 12:30 across 6 tools

Disambiguation5/5

Each tool maps to a distinct action: listing coverages, describing a coverage, learning WCPS basics, executing a query, listing doc chapters, and fetching a chapter. The documentation tools are explicitly tiered (crash course -> chapter index -> chapter body), so there is little risk of misselection.

Naming Consistency3/5

The names are in readable snake_case, but they mix bare verb_noun names (list_coverages, describe_coverage, execute_wcps_query) with wcps_-prefixed resource-style names (wcps_query_crash_course, wcps_doc_chapters, wcps_get_chapter). The prefix and verb placement are inconsistent even though the overall style is still navigable.

Tool Count5/5

Six tools is an appropriate size for a rasdaman querying server: coverage discovery, metadata inspection, query execution, and three levels of documentation. No tool feels redundant or missing at a high level.

Completeness4/5

The discover -> describe -> learn -> execute -> debug workflow is well covered. Minor gaps include a lack of write/ingest/update/delete operations for coverages and no explicit way to retrieve the contents of large result files, but these are likely outside the server's query-focused scope.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Sugra API A
ai.sugra
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Search Open Data Data Platforms
1122
mcp AOAuth
co.axiom
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Databases Monitoring Search
2729
MetehanGZL-pokemcpOAuth
ai.smithery
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…
Search Open Data
2
NASA Earthdata MCP A
io.github.nasa
Discover, verify, and access NASA Earth science datasets via the Common Metadata Repository (CMR)
Open Data Research & Data Government Data
71

Related MCP Servers

Rasdaman MCP Server
Databases Research & Data
fastmcp-me
A
license
A
quality
D
maintenance
Enables natural language interaction with rasdaman databases, allowing users to list coverages, describe datacubes, and execute WCPS queries.
Updated 7 months ago (2026-02-10 21:19 UTC)
5
MIT
mcp-geo-server
Location Services Databases
agent-engineering-studio
A
license
B
quality
C
maintenance
Enables natural language interaction with a GeoServer instance for managing workspaces, datastores, feature types, layers, styles, and OGC services (WMS/WFS) via an LLM-powered agent.
Updated 10 days ago (2026-09-03 16:51 UTC)
1
MIT
Geo-INQUIRE MCP Server
Location Services Research & Data
lukwe
F
license
Not graded
quality
B
maintenance
Enables interaction with Geo-INQUIRE OGC API Processes for geospatial operations, including planning, execution, and job management through natural language.
Updated 2 months ago (2026-07-09 14:37 UTC)
-
groundstation
Search Weather Services Location Services
dannybauman
F
license
A
quality
B
maintenance
Enables AI agents to query Earth observation data, satellite imagery, active fires, and weather via natural language, returning interactive maps and briefs.
Updated 10 days ago (2026-09-03 16:22 UTC)
12
-

Rasdaman MCP Server

Installation

Usage

stdio Mode

http Mode

AI agents

Examples

Listing Coverages

Describing a Coverage

Executing a Query

Query Result Visualization

Natural Language Query Suggestion

Development

Setup

Core Components

Defined Tools

Documentation

Automated Tests

Manual Testing

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`stdio` Mode

`http` Mode