Submit a data subset request to GDEX. Requires GDEX_TOKEN.
Args:
request_json: JSON string of the subsetting request body. Use get_control_file_template
to get the expected structure for a dataset, or validate_subset_request
to check it before submitting.
| Name | Required | Description | Default |
|---|---|---|---|
| request_json | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does disclose that GDEX_TOKEN is required, which is useful, but it omits important side effects such as whether the request is asynchronous, whether it returns a request ID, or how it relates to status-checking via check_request_status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the purpose and auth requirement first, then gives the argument explanation. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for preparing a request but incomplete about the submission lifecycle. It does not mention whether the tool waits for completion or only queues a request, which is material given the submit_and_wait_for_request sibling. The output schema exists, but behavioral context is still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description coverage for request_json, so the description must compensate. It explains that request_json is a JSON string of the subsetting request body and points to get_control_file_template and validate_subset_request for structure and validation, adding real guidance beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Submit a data subset request to GDEX.' It conveys the primary action and target system, though it does not explicitly differentiate itself from the sibling submit_and_wait_for_request beyond relying on the name difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage context by directing users to get_control_file_template for the request structure and validate_subset_request for pre-submission checking. It does not explicitly state when to choose this tool over submit_and_wait_for_request, but the preparation workflow is clearly outlined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.