MCP-TY

by qinsehm1128

Overview Schema Source Related Servers Discussions Admin

Python

Local

stop_project

Terminate the MCP-TY server's ty type checker process to free up system resources when analysis is complete.

Instructions

Stop ty and release resources.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "stop_project"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Implementation Reference

src/mcp_ty/server.py:330-343 (handler)

Implementation of the stop_project tool which stops the LSP client and releases resources.

@mcp.tool()
async def stop_project() -> str:
    """Stop ty and release resources."""
    global _lsp_client

    if _lsp_client is None:
        return _ok({"stopped": True, "message": "No active project"})

    try:
        await _lsp_client.stop()
        _lsp_client = None
        return _ok({"stopped": True})
    except Exception as e:
        return _error(str(e))

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Mar 25, 2026

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations provided, the description must carry full behavioral disclosure but only mentions 'release resources'. It lacks critical details: whether shutdown is graceful or forced, whether state/data is persisted, cleanup scopes, or the return value structure (despite having an output schema).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

Extremely terse (single fragmented sentence), which would be acceptable if accurate, but contains the typo 'ty' that undermines clarity. Every word should earn its place; here 'ty' wastes the agent's interpretive effort.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 0 parameters and an existing output schema, the burden is low, but the description fails to adequately explain what 'ty' refers to or the nature of the stopping operation. For a lifecycle operation (see sibling start_project), the ambiguity is insufficient.

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?

Input schema has zero parameters. Per rubric baseline for 0 params is 4. No parameters require semantic elaboration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description contains a critical typo ('Stop ty' instead of likely 'Stop the project'), making the actual target ambiguous. While 'release resources' adds some context, the core object of the action is unclear, forcing the user to infer from the tool name and sibling 'start_project'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to invoke this tool versus alternatives, nor prerequisites for use. The sibling 'start_project' exists but is not referenced to clarify the workflow relationship.

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

Deploy Server