Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@The Trench MCP Server What is the current simulation state?"
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.
MCP Server for controlling satellite ground station operations in the Trench simulation.
get_simulation_state() - Get comprehensive simulation state including satellite position, contact status, and timing
get_current_time() - Get current simulation time and real-world UTC time
restart_simulation() - Restart simulation from beginning, resetting all state to epoch time
get_all_passes() - Get complete schedule of all satellite passes over ground station
get_next_pass() - Get information about next upcoming satellite pass
get_current_pass() - Get information about currently active satellite pass (if any)
wait_until_time(target_sim_time) - Wait until simulation reaches specific time (seconds since epoch)
wait_for_next_pass() - Wait until next satellite pass begins (AOS)
start_downlink(kb_requested, max_minutes=10) - Start data downlink session during active pass
stop_downlink() - Stop current data downlink session
get_ground_station_state(gs_id="DEMO-GS") - Get current antenna position and mode
point_antenna(azimuth, elevation, gs_id="DEMO-GS") - Point antenna to specific angles
track_satellite(sat_id="LEO-001", gs_id="DEMO-GS") - Start automatic satellite tracking
stop_tracking(gs_id="DEMO-GS") - Stop satellite tracking, return to idle
park_antenna(gs_id="DEMO-GS") - Park antenna in safe position
get_satellite_health(sat_id="LEO-001") - Get satellite health and telemetry information
All tools use authenticated API calls with Bearer token authorization to interact with the Trench simulation API.
Related MCP server: spacetrack-mcp
To use this server with the Claude Desktop app, add the following configuration to the "mcpServers" section of your claude_desktop_config.json:
{
"mcpServers": {
"trench-mcp-server": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/jasonmeverett/the-trench-mcp@main",
"run-server"
],
"env": {
"TRENCH_API_URL": "https://the-trench.ml-2cba638a-03a.eng-ml-i.svbr-nqvp.int.cldr.work/",
"TRENCH_API_KEY": "<apiv2 key>"
}
}
}
}The MCP server's transport protocol is configurable via the MCP_TRANSPORT environment variable. Supported values:
stdio (default) — communicate over standard input/output. Useful for local tools, command-line scripts, and integrations with clients like Claude Desktop.
http - expose an HTTP server. Useful for web-based deployments, microservices, exposing MCP over a network.
sse — use Server-Sent Events (SSE) transport. Useful for existing web-based deployments that rely on SSE.
Get information about all passes defined in the scenario. Shows complete schedule of satellite passes over the ground station.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the tool is read-only in nature and returns schedule information, but does not describe the return format, time fields, or any error behavior. For a simple no-parameter 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, concise sentences with no wasted words. The core purpose is stated first, and the follow-up sentence reinforces the scope and output type.
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?
For a tool with no parameters, no annotations, and no output schema, the description provides enough high-level information about what the tool returns (complete schedule of all passes) for an agent to select and invoke it. It could mention returned fields, but it is not critically incomplete.
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 tool has zero parameters, and the schema coverage is 100%. The description does not need to explain parameter semantics because there are none to explain, so the baseline 4 applies.
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 clearly states the tool's purpose: retrieving information about all satellite passes in the scenario, specifying the complete schedule. This distinguishes it from sibling tools like get_next_pass, which targets a single pass.
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 conveys a clear usage context: obtaining the full pass schedule. It does not explicitly name alternatives or exclusions, but the plural 'all passes' and 'complete schedule' signal when this tool is appropriate relative to the singular get_next_pass.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current simulation time and real-world UTC time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. The verb 'Get' signals a non-mutating operation, and the description explicitly names the two returned values. It does not mention formatting or side effects, but none are expected for a simple getter.
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?
A single, front-loaded sentence conveys both the action and the returned data with zero wasted words. It is an ideal length for a tool this simple.
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 tool is maximally simple: no parameters, no annotations, no output schema. The description completely covers what the tool does and what it returns, making it fully selectable and callable by an agent without additional inference.
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 tool has zero parameters, so there is no parameter documentation burden. The description appropriately focuses on the output rather than inputs, which is the only relevant information for an agent.
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 uses a specific verb ('Get') and clearly identifies both resources: the simulation time and real-world UTC time. It is instantly distinguishable from sibling tools like wait_until_time or downlink operations.
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 context clearly implies a read-only, non-blocking time lookup, which separates it from wait_until_time and pass/downlink tools. It does not explicitly state when not to use it, but with a zero-parameter tool the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the next upcoming satellite pass. Returns None if no future passes are scheduled.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does well by indicating this is a read-only information getter and explicitly stating that it returns None when no future passes exist, which is an important edge case.
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 two short sentences with no fluff. The main purpose is front-loaded, and the second sentence adds a meaningful edge-case behavior. Every word earns its place.
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?
For a zero-argument read-only tool, the description is mostly sufficient, but there is no output schema and the description never explains what 'information' actually includes. An agent may not know what fields or structure the returned pass information will have, which is a meaningful gap.
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 tool has no parameters, so there is no parameter-level semantics to document. The baseline for zero-parameter tools is 4, and the description correctly needs no parameter explanation.
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 clearly states the operation: get information about the next upcoming satellite pass. It is distinguishable from get_all_passes because it explicitly targets only the next pass, and the None edge case makes the behavior more concrete.
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 clear context for when to use the tool: when information about the next upcoming pass is needed. It doesn't explicitly mention alternatives like get_all_passes, but the 'next upcoming' wording implies a natural contrast with getting all passes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a data downlink session with default parameters (no arguments required). Must be called during an active satellite pass.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It usefully discloses a precondition (active satellite pass), but it does not describe what happens if the precondition is not met, whether a session can be started when one is already active, or other side effects of starting the downlink session.
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 two concise sentences, front-loaded with the core action and immediately followed by the key precondition. Every sentence earns its place with no redundancy.
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?
For a no-argument, simple start action, the description covers the essential information: what the tool does and when it must be called. It is complete enough to invoke correctly, though it omits minor behavioral details like failure behavior if no satellite pass is active.
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 has zero parameters and the description reinforces that by explicitly stating 'no arguments required' and 'default parameters.' With no parameters, the baseline is 4, and the description adds helpful confirmation that no input is needed.
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 states a specific verb and resource: 'Start a data downlink session.' It clearly distinguishes this from the sibling stop_downlink_simple and other non-downlink tools, so an agent can identify its purpose immediately.
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 provides a clear usage context: 'Must be called during an active satellite pass.' It does not explicitly discuss when not to use it or name alternative tools, but for a simple start action the precondition is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the current data downlink session (no arguments required). Returns complete downlink status including total data downloaded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose that the tool stops a session and returns complete status including total data downloaded. But it does not state what happens if no session is active, whether stopping is reversible, or whether any downloaded data is retained.
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?
Two compact sentences with no wasted words. The core action is front-loaded, and the return-value note earns its place.
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?
For a zero-argument tool with no output schema, the description covers the action and the return value. It could be slightly more complete by addressing the no-active-session edge case, but overall it gives enough context to invoke the tool correctly.
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?
There are zero parameters, and the description explicitly notes 'no arguments required,' which prevents an agent from inventing arguments. The empty schema already implies this, but the description reinforces it clearly.
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 states a specific verb ('Stop') and a specific resource ('the current data downlink session'), which clearly distinguishes it from siblings like start_downlink_simple. The meaning is immediately unambiguous.
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 usage context is implied by the wording: it stops the current downlink session, so it would be used when an active downlink exists. However, it never explicitly names start_downlink_simple as the counterpart or says when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test the connection to the Trench API server. Useful for debugging connectivity issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Test the connection' implies a non-destructive network check, but it does not describe what the tool actually does beyond that, such as whether it sends a request, returns a status, or how failures are reported. The description is not misleading, but it is thin.
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 two short sentences with no filler. The primary purpose is stated first, followed by a practical usage hint. Every word earns its place.
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?
For a zero-parameter, no-output-schema diagnostic tool, the description is largely complete: it names the target server, the action, and the practical use case. It does not describe the response or success criteria, which would be useful, but this is a minor gap for such a simple tool.
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 tool has zero parameters, so the schema already fully documents the input surface. The description does not need to explain parameter behavior, and it appropriately avoids inventing unnecessary details. Baseline 4 applies.
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 states a specific action ('Test the connection') and a specific resource ('the Trench API server'). It is clearly distinct from sibling tools, which focus on time queries and downlink operations, so an agent can easily tell what this tool is for.
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 phrase 'Useful for debugging connectivity issues' provides explicit guidance on when to use this tool. It does not mention when not to use it or suggest an alternative, but for a simple connectivity check this context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait until the simulation reaches a specific UTC time. Polls the simulation every 0.1 seconds until the target time is reached.
Args: target_time_iso: Target UTC time in ISO format (e.g., "2025-09-15T17:30:00Z")
| Name | Required | Description | Default |
|---|---|---|---|
| target_time_iso | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral transparency. It discloses the polling interval (every 0.1 seconds) and the blocking 'wait until target time is reached' behavior. It does not mention timeout or behavior for past times, but the core execution model is clearly conveyed.
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 brief and well-organized: a one-sentence purpose statement, one sentence on behavior, and a compact Args block. Every sentence earns its place with no redundant fluff.
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?
For a simple single-parameter tool with no output schema, the description provides the essential details: purpose, behavior, and parameter format. It could mention edge cases like past times or infinite waiting, but these are reasonable omissions given the tool's simplicity.
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?
Schema description coverage is 0%, so the description must fully compensate. It defines target_time_iso as 'Target UTC time in ISO format' and provides a concrete example ('2025-09-15T17:30:00Z'), adding all necessary meaning beyond the bare schema type and required flag.
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 clearly states the tool's action with a specific verb and resource: 'Wait until the simulation reaches a specific UTC time.' This is not a tautology of the name and effectively distinguishes it from sibling tools like get_current_time, which reads the current time rather than waiting.
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 context of use is clear: it blocks the simulation until a target time, with polling every 0.1 seconds. It implies the agent should use this instead of manually polling get_current_time, though it does not explicitly mention alternatives or exclusions. No misleading guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_all_passesget_current_timeget_next_passstart_downlink_simplestop_downlink_simpletest_api_connectionwait_until_timeScored across 7 tools
Each tool targets a distinct concern: connectivity, time, pass scheduling (all vs. next), waiting, and downlink start/stop. Although get_all_passes and get_next_pass are related, their names and descriptions make the difference immediately clear.
Tool names consistently follow a verb_noun pattern with snake_case, such as test_api_connection, get_all_passes, and start_downlink_simple. The pattern is predictable and uniform across the entire set.
Seven tools is an appropriate, focused scope for a satellite ground-station simulation/downlink server. Each tool covers a necessary operation without redundancy or bloat.
The tool set covers the full workflow: verifying connectivity, checking simulation time, discovering passes, waiting for the right moment, and starting/stopping downlinks. No critical dead ends are apparent for the stated domain.
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
MCP server for Mireye Earth — federal-source-cited geospatial data for any MCP-aware agent.
An MCP server that provides Javelin Standalone Guardrails
