Skip to main content
Glama
dylan-gluck

MCP Background Job Server

by dylan-gluck

interact_with_job

Send input to a running background job's standard input and receive immediate output responses for interactive process management.

Instructions

Send input to a job's stdin and return any immediate output.

Args: job_id: The UUID of the job to interact with input: Text to send to the job's stdin

Returns: ProcessOutput containing any immediate stdout/stderr output after sending input

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesJob ID to interact with
inputYesInput to send to the job's stdin

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
stderrYesStandard error content
stdoutYesStandard output content

Implementation Reference

  • MCP tool handler for 'interact_with_job': sends user input to a background job's stdin and returns immediate output, with error handling and proxying to JobManager service.
    @mcp.tool()
    async def interact_with_job(
        job_id: str = Field(..., description="Job ID to interact with"),
        input: str = Field(..., description="Input to send to the job's stdin"),
    ) -> ProcessOutput:
        """Send input to a job's stdin and return any immediate output.
    
        Args:
            job_id: The UUID of the job to interact with
            input: Text to send to the job's stdin
    
        Returns:
            ProcessOutput containing any immediate stdout/stderr output after sending input
        """
        try:
            job_manager = get_job_manager()
            interaction_result = await job_manager.interact_with_job(job_id, input)
            return interaction_result
        except KeyError:
            raise ToolError(f"Job {job_id} not found")
        except RuntimeError as e:
            if "not running" in str(e):
                raise ToolError(f"Job {job_id} is not running and cannot accept input")
            else:
                raise ToolError(f"Failed to interact with job: {str(e)}")
        except Exception as e:
            logger.error(f"Error interacting with job {job_id}: {e}")
            raise ToolError(f"Failed to interact with job: {str(e)}")
  • Core JobManager method implementing interact_with_job logic: validates job is running, sends input to process stdin via ProcessWrapper, and returns output.
    async def interact_with_job(self, job_id: str, input_text: str) -> ProcessOutput:
        """Send input to job stdin, return immediate output.
    
        Args:
            job_id: Job identifier
            input_text: Text to send to stdin
    
        Returns:
            ProcessOutput with any immediate stdout/stderr output
    
        Raises:
            KeyError: If job_id doesn't exist
            RuntimeError: If job is not running or stdin not available
        """
        if job_id not in self._jobs:
            raise KeyError(f"Job {job_id} not found")
    
        # Update job status first
        await self._update_job_status(job_id)
    
        job = self._jobs[job_id]
        if job.status != JobStatus.RUNNING:
            raise RuntimeError(f"Job {job_id} is not running (status: {job.status})")
    
        process_wrapper = self._processes.get(job_id)
        if process_wrapper is None:
            raise RuntimeError(f"Process wrapper for job {job_id} not found")
    
        return await process_wrapper.send_input(input_text)
Behavior2/5

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 mentions sending input and returning immediate output, but lacks details on behavioral traits such as whether this requires specific job states (e.g., running), if it blocks until output is available, potential rate limits, or error handling. For a tool that interacts with processes, this is a significant gap in transparency.

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 front-loaded with the core purpose in the first sentence, followed by structured sections for Args and Returns. Each sentence earns its place by clarifying parameters and return values without redundancy, making it efficient and well-organized.

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 of job interaction, no annotations, and an output schema (implied by 'Returns' section), the description is mostly complete. It covers purpose, parameters, and return values, but lacks behavioral context like job state requirements or error scenarios, which would be beneficial for full completeness.

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?

Schema description coverage is 100%, so the schema already documents both parameters (job_id and input) with descriptions. The description adds minimal value beyond the schema by reiterating that job_id is a UUID and input is text for stdin, but doesn't provide additional semantics like format constraints or examples. Baseline 3 is appropriate as the schema does the heavy lifting.

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 specific action ('Send input to a job's stdin') and resource ('a job'), distinguishing it from siblings like get_job_output (which retrieves output without sending input) or kill_job (which terminates a job). The verb 'send' and resource 'job's stdin' are precise and unambiguous.

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 implies usage context by specifying 'send input to a job's stdin,' suggesting it's for interacting with an active job, but it doesn't explicitly state when to use this versus alternatives like get_job_output (for reading output without input) or execute_command (for starting new jobs). No exclusions or prerequisites are mentioned, though the context is 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/dylan-gluck/mcp-background-job'

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