Skip to main content
Glama
saidsef

GitHub PR Issue Analyser

by saidsef

get_info

Fetch structured data from any URL via HTTP GET requests to retrieve JSON information for analysis and processing.

Instructions

Fetches information from the specified URL using an HTTP GET request. Args: url (str): The URL to send the GET request to. Returns: Dict[str, Any]: The JSON response parsed into a dictionary if the request is successful. Returns an empty dictionary if the request fails or an exception occurs. Error Handling: Logs an error message and stack trace if a requests.RequestException is raised during the HTTP request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The core handler function for the MCP tool 'get_info'. It performs an HTTP GET request to the provided URL, parses the JSON response, and handles errors by logging and returning an error dictionary.
    def get_info(self, url: str) -> Dict[str, Any]:
      """
      Fetches information from the specified URL using an HTTP GET request.
      Args:
          url (str): The URL to send the GET request to.
      Returns:
          Dict[str, Any]: The JSON response parsed into a dictionary if the request is successful.
          Returns an empty dictionary if the request fails or an exception occurs.
      Error Handling:
          Logs an error message and stack trace if a requests.RequestException is raised during the HTTP request.
      """
        
      try:
          response = requests.get(url, timeout=TIMEOUT)
          response.raise_for_status()
          return response.json()
      except requests.RequestException as e:
          logging.error(f"Error fetching IP info: {e}")
          logging.debug(e)
          traceback.print_exc()
          return {"error": str(e)}
  • The registration logic that dynamically discovers and registers all public methods (non-starting with '_') from IPIntegration instance as MCP tools, including 'get_info', by calling mcp.add_tool(method). This is invoked at line 107 for self.ip.
    def register_tools(self, methods: Any = None) -> None:
        for name, method in inspect.getmembers(methods):
            if (inspect.isfunction(method) or inspect.ismethod(method)) and not name.startswith("_"):
                self.mcp.add_tool(method)
  • Usage of get_info as a helper in get_ipv4_info tool to fetch IPv4 data from ipinfo.io
    def get_ipv4_info(self) -> Dict[str, Any]:
        """
        Get information about an IPv4 address.
        :return: A dictionary containing the IPv4 information.
        """
        try:
            ipv4 = self.get_info(self.ipv4_api_url)
            if not ipv4:
                logging.error("No IPv4 information found.")
                return {}
            return ipv4
        except requests.RequestException as e:
            logging.error(f"Error fetching IPv4 info: {e}")
            logging.debug(e)
            traceback.print_exc()
            return {"error": str(e)}
  • Usage of get_info as a helper in get_ipv6_info tool to fetch IPv6 data from v6.ipinfo.io, with IPv6 family override.
    def get_ipv6_info(self) -> Dict[str, Any]:
      """
      Retrieves IPv6 information from a specified API endpoint.
      This method temporarily overrides the `allowed_gai_family` method to force the use of IPv6 when making network requests.
      It then attempts to fetch IPv6-related information from the configured API URL.
      Returns:
          dict: A dictionary containing IPv6 information if the request is successful.
                Returns an empty dictionary if no information is found or if an error occurs.
      Error Handling:
          Logs an error message and returns an empty dictionary if a `requests.RequestException` is raised during the fetch operation.
          Also logs the full traceback at the debug level for troubleshooting.
      """
      try:
          urllib3_connection.allowed_gai_family = lambda: socket.AF_INET6
          ipv6 = self.get_info(self.ipv6_api_url)
          if not ipv6:
              logging.error("No IPv6 information found.")
              return {"error": "No IPv6 information found."}
          return ipv6
      except requests.RequestException as e:
          logging.error(f"Error fetching IPv6 info: {e}")
          logging.debug(e)
          traceback.print_exc()
          return {"error": f"Failed to fetch IPv6 information: {str(e)}"}
  • Calls register_tools on the IPIntegration instance (self.ip), which triggers registration of 'get_info' and other public methods as MCP tools.
    def _register_tools(self):
        self.register_tools(self.gi)
        self.register_tools(self.ip)
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it performs an HTTP GET request, returns a JSON response as a dictionary on success, returns an empty dictionary on failure, and logs errors with stack traces for exceptions. This covers the core operational behavior without contradictions.

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 well-structured and front-loaded with the main purpose, followed by organized sections for Args, Returns, and Error Handling. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 moderate complexity (HTTP GET with error handling), no annotations, and an output schema present, the description is mostly complete. It explains the purpose, parameters, return values, and error handling, but could benefit from more details on authentication, rate limits, or specific use cases to enhance context.

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?

The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that the 'url' parameter is for sending the GET request to, clarifying its purpose. Since there is only one parameter and the schema lacks descriptions, the description compensates well, though it could provide more details like URL format constraints.

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's purpose with a specific verb ('fetches information') and resource ('from the specified URL using an HTTP GET request'). It distinguishes itself from sibling tools by focusing on HTTP GET requests rather than GitHub operations like PRs, issues, or releases.

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 for fetching information via HTTP GET, but does not explicitly state when to use this tool versus alternatives like sibling tools (e.g., get_ipv4_info, get_pr_content). It provides some context by mentioning error handling, but lacks explicit guidance on use cases or exclusions.

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/saidsef/mcp-github-pr-issue-analyser'

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