Skip to main content
Glama
patrickkabwe

React Native Upgrader MCP

by patrickkabwe

Get User Desired Version of React Native

get-user-version

Specify the target React Native version for upgrading your project, enabling preview of changes before migration.

Instructions

Gets the version of React Native that the user wants to upgrade to.

OVERVIEW: This tool is used to get the version of React Native that the user wants to upgrade to.

USAGE: • This tool is used to get the version of React Native that the user wants to upgrade to. • The version can be used with the "get-react-native-diff" tool to preview changes before upgrading.

IMPORTANT NOTES: • The version must be a valid semantic version number. e.g. 0.72.0 • The version must be a valid release candidate version number. e.g. 0.72.0-rc.0 • If the version is not a valid semantic version number or release candidate version number, the tool should provide a message that asks the user to provide a valid version. • If the user wants to upgrade to the latest stable version, call the get-stable-version tool to get the latest stable version. • If the user wants to upgrade to the latest release candidate version, call the get-rc-version tool to get the latest release candidate version.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
versionYesThe version of React Native that the user wants to upgrade to

Implementation Reference

  • The handler function for the 'get-user-version' tool. It takes the input 'version' parameter and returns it as text content in the response.
    async ({ version }) => {
        return {
            content: [{ type: "text", text: version }]
        }
    });
  • The input schema for the 'get-user-version' tool, defining a single string parameter 'version'.
    inputSchema: {
        version: z.string().describe("The version of React Native that the user wants to upgrade to")
    }
  • src/tools.ts:7-34 (registration)
    The registration of the 'get-user-version' tool on the MCP server, including title, description, input schema, and handler function.
        server.registerTool('get-user-version', {
            title: "Get User Desired Version of React Native",
            description: `Gets the version of React Native that the user wants to upgrade to.
    
    OVERVIEW:
    This tool is used to get the version of React Native that the user wants to upgrade to.
    
    USAGE:
    • This tool is used to get the version of React Native that the user wants to upgrade to.
    • The version can be used with the "get-react-native-diff" tool to preview changes before upgrading.
    
    IMPORTANT NOTES:
    • The version must be a valid semantic version number. e.g. 0.72.0
    • The version must be a valid release candidate version number. e.g. 0.72.0-rc.0
    • If the version is not a valid semantic version number or release candidate version number, the tool should provide a message that asks the user to provide a valid version.
    • If the user wants to upgrade to the latest stable version, call the get-stable-version tool to get the latest stable version.
    • If the user wants to upgrade to the latest release candidate version, call the get-rc-version tool to get the latest release candidate version.
    `,
    
            inputSchema: {
                version: z.string().describe("The version of React Native that the user wants to upgrade to")
            }
        },
            async ({ version }) => {
                return {
                    content: [{ type: "text", text: version }]
                }
            });
Behavior4/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 discloses key behavioral traits: the tool validates input (e.g., requires valid semantic version or release candidate version), provides error messages for invalid input, and interacts with other tools (e.g., 'get-react-native-diff' for previewing changes). This adds valuable context beyond the basic schema, though it could mention output format or error handling details.

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

Conciseness3/5

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

The description is structured with sections like OVERVIEW, USAGE, and IMPORTANT NOTES, but it is repetitive (e.g., restating the purpose multiple times) and includes unnecessary bullet points that could be condensed. While it provides useful information, it lacks efficiency, with sentences that do not all earn their place.

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 tool's complexity (simple parameter, no annotations, no output schema), the description is fairly complete. It covers purpose, usage guidelines, behavioral traits, and parameter semantics adequately. However, it could improve by specifying the output format or error details, but it compensates well with context on sibling tools and validation.

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 input schema has 100% description coverage, with the parameter 'version' documented as 'The version of React Native that the user wants to upgrade to.' The description adds some semantics by specifying version format requirements (e.g., semantic version, release candidate) and validation behavior, but this largely reinforces the schema. Baseline is 3 since the schema does the heavy lifting.

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 the tool's purpose: 'Gets the version of React Native that the user wants to upgrade to.' It specifies the verb ('gets') and resource ('version of React Native'), but does not explicitly differentiate it from sibling tools like 'get-stable-version' or 'get-rc-version' beyond mentioning them as alternatives. This makes it clear but not fully distinct from siblings.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool versus alternatives. It states: 'If the user wants to upgrade to the latest stable version, call the get-stable-version tool' and 'If the user wants to upgrade to the latest release candidate version, call the get-rc-version tool.' This clearly defines usage contexts and exclusions, helping the agent select the correct tool.

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/patrickkabwe/react-native-upgrader-mcp'

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