Skip to main content
Glama
PurdueRCAC

Globus MCP Server

by PurdueRCAC

compute_submit

Submit a Python function for remote execution on a Globus Compute endpoint and receive a task ID for asynchronous tracking.

Instructions

Submit a Python function for remote execution on a Globus Compute endpoint.

The function is provided as Python source code. All imports MUST be inside the function body. The function is registered, then submitted asynchronously — this tool returns immediately with a task ID.

IMPORTANT: If your function uses any third-party packages, you MUST provide a 'requirements' string listing them (one per line, like a requirements.txt). This is used to provision a virtual environment on the remote endpoint automatically.

Args: endpoint_id: UUID of the target Compute endpoint. Use compute_endpoint_list() to find available endpoints. function_source: Python source code containing the function. Example: "def analyze(data_path):\n import pandas as pd\n ..." function_name: Name of the function defined in function_source. requirements: Newline-separated pip requirements for the function's dependencies (e.g. "numpy\npandas>=2.0\nscipy"). Omit if the function only uses the standard library. args: Positional arguments to pass to the function. kwargs: Keyword arguments to pass to the function. python_version: Python version for the remote venv (e.g. "3.12"). Defaults to the version running in this server. user_endpoint_config: Additional endpoint configuration. If this contains a 'worker_init' key, it overrides the auto-generated worker_init from requirements.

Returns: Dict with 'task_ids' (list of task UUID strings) and 'function_id'.

Examples: compute_submit( endpoint_id="abcd-1234-...", function_source="def hello():\n return 'Hello from HPC!'", function_name="hello", )

compute_submit(
    endpoint_id="abcd-1234-...",
    function_source="def analyze(n):\n    import numpy as np\n    return np.random.rand(n).mean()",
    function_name="analyze",
    requirements="numpy",
    args=[1000],
)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endpoint_idYes
function_sourceYes
function_nameYes
requirementsNo
argsNo
kwargsNo
python_versionNo
user_endpoint_configNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses asynchronous behavior, registration step, return format (task_ids and function_id), and auto-generation of worker_init. Does not mention error handling or timeouts, but covers key behaviors.

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?

Well-structured with overview, important note, Args section, Returns, and Examples. Each sentence adds value, no redundancy. Front-loaded with purpose. Efficient use of space given the complexity.

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 complexity (8 parameters, no annotations, output schema exists), the description is thorough. Covers workflow, parameter details, constraints, and examples. Could mention that function_source must be a valid function definition, but this is implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and description compensates fully. Each parameter is explained with purpose, format, and defaults. Examples demonstrate usage for multiple scenarios, including optional parameters like requirements and args. Adds significant value beyond the schema.

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 submits a Python function for remote execution on a Globus Compute endpoint. It uses a specific verb ('submit') and identifies the resource ('Python function for remote execution'). It distinguishes from sibling tools like compute_batch_submit and compute_result by focusing on single function submission.

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?

Provides context on asynchronous submission, immediate return, and requirements for third-party packages. References sibling tool compute_endpoint_list() for finding endpoints. Does not explicitly state when not to use this tool or compare to alternatives, but the constraints are clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PurdueRCAC/globus-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server