Skip to main content
Glama
rossumai

Rossum MCP Server

Official
by rossumai

rossum_get_hooks

Retrieve all serverless function hooks from the Rossum organization for analysis and integration purposes.

Instructions

Get all serverless function hooks from the Rossum organization.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main MCP tool handler for 'rossum_get_hooks', registered via @mcp.tool() decorator. It delegates to the _get_hooks_impl() helper for the actual API interaction.
    @mcp.tool()
    async def rossum_get_hooks() -> List[Dict[str, Any]]:
        """Get all serverless function hooks from the Rossum organization."""
        return await _get_hooks_impl()
  • Core implementation logic for fetching hooks: defines summary keys and calls the paginated request helper to retrieve hooks from Rossum API endpoint '/hooks'.
    async def _get_hooks_impl() -> List[Dict[str, Any]]:
        """Get all hooks with essential fields only, handling pagination."""
        summary_keys = ["id", "name", "type", "url", "active", "events", "queues"]
        return await _rossum_unpaginated_request("GET", "/hooks", summary_keys=summary_keys)
  • Reusable helper for making paginated requests to Rossum API, collecting all pages of results and optionally summarizing to specific keys. Used by _get_hooks_impl().
    async def _rossum_unpaginated_request(method: str, path: str, summary_keys: Optional[List[str]] = None) -> List[Dict[str, Any]]:
        """Make a request to the Rossum API, handling pagination and summarization."""
        all_items = []
        current_path = path
    
        while current_path:
            try:
                page_data = await _rossum_request(method, current_path)
            except Exception as e:
                # Log or handle error, for now re-raising.
                # Consider logging: print(f"Error fetching Rossum data from {current_path}: {e}")
                raise
    
            if page_data and "results" in page_data and isinstance(page_data.get("results"), list):
                for item in page_data["results"]:
                    if summary_keys:
                        summary_item = {key: item.get(key) for key in summary_keys if key in item}
                        all_items.append(summary_item)
                    else:
                        all_items.append(item)  # Append the full item if no summary_keys
            
            pagination_info = page_data.get("pagination") if page_data else None
            next_page_url = pagination_info.get("next") if pagination_info else None
            
            if next_page_url:
                if next_page_url.startswith(ROSSUM_API_BASE):
                    current_path = next_page_url[len(ROSSUM_API_BASE):]
                else:
                    # Consider logging: print(f"Warning: next_page_url {next_page_url} does not match ROSSUM_API_BASE")
                    current_path = None 
            else:
                current_path = None
    
        return all_items
  • Low-level HTTP request helper to Rossum API, handles auth headers, errors, and JSON parsing. Called by paginated request helper.
    async def _rossum_request(method: str, path: str, **kwargs) -> Any:
        """Make a request to the Rossum API"""
        try:
            response = await client.request(
                method=method,
                url=f"{ROSSUM_API_BASE}{path}",
                headers=await get_rossum_headers(),
                **kwargs
            )
            response.raise_for_status()
            
            # Handle cases where Rossum might return empty body on success (e.g., 204)
            if response.status_code == 204:
                return None 
            return response.json()
        except httpx.HTTPStatusError as e:
            # Get error detail from response if possible
            error_detail = str(e)
            try:
                error_detail = e.response.json()
            except Exception:
                pass
            raise Exception(f"Rossum API error {e.response.status_code}: {error_detail}")
        except httpx.RequestError as e:
            raise Exception(f"Rossum API request failed: {str(e)}")
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 of behavioral disclosure. It states it retrieves 'all' hooks, implying a list operation, but doesn't disclose any behavioral traits such as pagination, rate limits, authentication requirements, or error handling. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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 a single, clear sentence that efficiently conveys the tool's purpose without any wasted words. It is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by specifying what is being retrieved and from where.

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's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks details on behavioral aspects like response format or error conditions. For a basic read operation, it meets minimum viability but could be more informative about the return value or usage 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter information, which is appropriate here. A baseline of 4 is applied for tools with zero parameters, as there's nothing to compensate for and the description doesn't introduce confusion.

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 action ('Get all') and resource ('serverless function hooks from the Rossum organization'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'rossum_get_hook' (singular vs plural), but the scope is clear. The description avoids tautology by specifying what is being retrieved rather than just restating the name.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'rossum_get_hook' (for a single hook) or other get operations, nor does it specify any prerequisites or contextual constraints. The agent must infer usage from the tool name and description alone.

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/rossumai/rossum-mcp-server'

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