Skip to main content
Glama
Sign In
Radicle + GitHub MCP Server

Radicle + GitHub MCP Server

by fovi-llc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

rad_help

Access documentation for Radicle commands to understand usage and options for peer-to-peer code collaboration.

Instructions

Get help for Radicle commands.

Args:
    command: Specific command to get help for (optional)

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": "rad_help"
  }
}

Input Schema

NameRequiredDescriptionDefault
commandNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • src/radicle_mcp/server.py:255-272 (handler)
    The handler function for the 'rad_help' tool. It runs 'rad --help' or 'rad <command> --help' using the run_rad_command helper and formats the output. The @mcp.tool() decorator registers it as an MCP tool. The function signature and docstring define the input schema.
    @mcp.tool()
async def rad_help(command: Optional[str] = None) -> str:
    """
    Get help for Radicle commands.
    
    Args:
        command: Specific command to get help for (optional)
    """
    if command:
        result = await run_rad_command(["rad", command, "--help"])
    else:
        result = await run_rad_command(["rad", "--help"])
    
    if result["success"]:
        return f"đź“– Radicle Help:\n{result['stdout']}"
    else:
        return f"❌ Failed to get help: {result['stderr']}"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
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 states the tool 'Get help' but doesn't disclose behavioral traits such as what format the help is returned in (e.g., text, markdown), whether it requires network access, if there are rate limits, or how it handles invalid commands. This leaves significant gaps for an agent to understand the tool's behavior beyond its basic purpose.

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

Conciseness4/5

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

The description is concise with two sentences: one stating the purpose and another explaining the parameter. It's front-loaded with the main purpose. However, the 'Args:' section is slightly redundant with the schema and could be integrated more smoothly, preventing a perfect score.

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

Completeness3/5

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

Given the tool has an output schema (which covers return values), the description doesn't need to explain outputs. However, with no annotations, 1 parameter at 0% schema coverage, and a simple purpose, the description is adequate but incomplete—it lacks behavioral context and detailed usage guidelines, making it minimally viable but with clear gaps.

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?

The description adds minimal semantics: it notes the 'command' parameter is optional and for getting help for a specific command. However, with 0% schema description coverage and 1 parameter, the schema already indicates it's a nullable string with default null. The description doesn't add meaningful details like command examples or constraints, so it meets the baseline of 3 for low parameter count but doesn't compensate for the lack of schema coverage.

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

Purpose4/5

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

The description clearly states 'Get help for Radicle commands' which is a specific verb ('Get help') and resource ('Radicle commands'). It distinguishes this tool from sibling tools like rad_clone, rad_init, etc., which perform actual operations rather than providing help. However, it doesn't explicitly contrast with a hypothetical 'general help' tool, keeping it at 4 rather than 5.

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

Usage Guidelines3/5

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

The description implies usage when needing help with Radicle commands, but doesn't explicitly state when to use this tool versus alternatives (e.g., when to use rad_help vs. checking documentation elsewhere). It mentions the optional 'command' parameter, suggesting it can be used for general or specific help, but lacks explicit guidance on scenarios or exclusions.

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

Deploy Server

Other Tools