Skip to main content
Glama
tizee

MCP-Server-IETF

by tizee

get_ietf_doc

Retrieve IETF RFC documents by number with pagination support, specifying start line and maximum lines to return. Access document content and metadata directly.

Instructions

Get an RFC document by its number in RFC editor Index with pagination support

Args:
    number: The RFC number str (e.g., "1234")
    start_line: The line number to start from (default: 1)
    max_lines: Maximum number of lines to return (default: 200)

Returns:
    A dictionary containing the document content and metadata

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_linesNo
numberYes
start_lineNo

Implementation Reference

  • The main async handler function implementing the logic for the 'get_ietf_doc' MCP tool. It retrieves the server context, calls the get_rfc_document helper with parameters, logs the result, and returns the document data.
    async def get_ietf_doc(
        ctx: Context,
        number: int,
        start_line: int = 1,
        max_lines: int = DEFAULT_MAX_LINES,
    ) -> Dict[str, Any]:
        """
        Get an RFC document by its number in RFC editor Index with pagination support
    
        Args:
            number: The RFC number str (e.g., "1234")
            start_line: The line number to start from (default: 1)
            max_lines: Maximum number of lines to return (default: 200)
    
        Returns:
            A dictionary containing the document content and metadata
        """
        server_ctx = ctx.request_context.lifespan_context
        data = get_rfc_document(str(number),
                                           start_line,
                                           max_lines,
                                           CACHE_DIR, server_ctx)
        logger.debug(f"get_doc: {data}")
        return data
  • Registers the get_ietf_doc function as a tool on the FastMCP server instance.
    @mcp.tool()
  • Core helper function that implements the document retrieval logic: input validation, index lookup, download/caching, pagination, metadata extraction including page info, and structured output.
    def get_rfc_document(
        rfc_number: str,
        start_line: int = 1,
        max_lines: int = 200,
        cache_dir: str = CACHE_DIR,
        index_data: Optional[RFCIndexData] = None
    ) -> Dict[str, Any]:
        """
        Get an RFC document by its number with pagination support
    
        Args:
            rfc_number: The RFC number (e.g., "1234")
            start_line: The line number to start from (default: 1)
            max_lines: Maximum number of lines to return (default: 200)
            cache_dir: Directory to store cached files
            index_data: Optional pre-loaded index data
    
        Returns:
            A dictionary containing the document content and metadata
        """
        # Validate input
        if not rfc_number.isdigit():
            return {"error": "RFC number must be a number"}
    
        if start_line < 1:
            return {"error": "start_line must be 1 or greater"}
    
        if max_lines < 1:
            return {"error": "max_lines must be 1 or greater"}
    
        # Get index data if not provided
        if index_data is None:
            index_path = download_rfc_index(cache_dir)
            index_data = parse_rfc_index(index_path)
    
        # Check if RFC exists in our index
        if rfc_number not in index_data.rfc_titles:
            return {"error": f"RFC {rfc_number} not found in index"}
    
        # Download RFC if needed
        try:
            doc_path = download_rfc(rfc_number, cache_dir)
        except Exception as e:
            return {"error": str(e)}
    
        # Read and paginate the document
        with open(doc_path, "r", encoding="utf-8") as f:
            all_lines = f.readlines()
            total_lines = len(all_lines)
    
            # Validate start_line
            if start_line > total_lines:
                return {"error": f"start_line ({start_line}) exceeds document length ({total_lines})"}
    
            # Calculate pagination
            end_line = min(start_line + max_lines - 1, total_lines)
            paginated_lines = all_lines[start_line-1:end_line]
            paginated_content = ''.join(paginated_lines)
    
            # Check if truncated
            truncated = end_line < total_lines
    
            # Extract page numbers if available by scanning the content
            page_info = extract_page_info(paginated_content)
    
        # Basic metadata
        title = index_data.rfc_titles.get(rfc_number, "Unknown title")
    
        return {
            "content": paginated_content,
            "title": title,
            "path": doc_path,
            "start_line": start_line,
            "end_line": end_line,
            "max_lines": max_lines,
            "total_lines": total_lines,
            "truncated": truncated,
            "truncated_at_line": end_line if truncated else None,
            "page_info": page_info,
            "next_chunk_start": end_line + 1 if truncated else None
        }
  • Dataclass defining the structure for RFC index data, used by get_rfc_document to check RFC existence and retrieve titles.
    @dataclass
    class RFCIndexData:
        """Data structure for RFC index information"""
        index_path: str
        docs_count: int
        rfc_titles: Dict[str, str]  # Map of RFC number to title
Behavior2/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 mentions 'pagination support' and describes the return format ('A dictionary containing the document content and metadata'), which adds some context. However, it lacks details on error handling (e.g., what happens if the RFC number doesn't exist), rate limits, authentication needs, or whether this is a read-only operation. For a tool with 3 parameters and no annotations, this leaves significant gaps.

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 well-structured and appropriately sized, with a clear purpose statement followed by 'Args:' and 'Returns:' sections. Each sentence adds value, such as explaining pagination and parameter defaults. There's no redundant or wasted text, making it efficient for an agent to parse.

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 complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers the basic purpose, parameters, and return format, but lacks details on behavioral aspects like error handling, rate limits, and differentiation from siblings. Without annotations or an output schema, more context on usage and behavior would improve completeness for reliable agent invocation.

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 explicitly lists all 3 parameters with brief explanations (e.g., 'The RFC number str', 'The line number to start from'), adding meaning beyond the input schema, which has 0% description coverage. However, it doesn't fully compensate for the schema's lack of descriptions—for example, it doesn't clarify the format of 'number' (though it gives an example '1234'), validate ranges for 'start_line' or 'max_lines', or explain edge cases. With 0% schema coverage, the description provides basic but incomplete parameter semantics.

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: 'Get an RFC document by its number in RFC editor Index with pagination support'. This specifies the verb ('Get'), resource ('RFC document'), and key functionality ('pagination support'). However, it doesn't explicitly differentiate from sibling tools like 'list_ietf_docs_number' or 'search_ietf_rfc_by_keyword', which likely serve different purposes (listing vs. searching).

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 mentions pagination support but doesn't explain when to use this tool over 'list_ietf_docs_number' (which might list documents) or 'search_ietf_rfc_by_keyword' (which might search by content). There's no mention of prerequisites, exclusions, or specific contexts for usage.

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

Related 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/tizee/mcp-server-ietf'

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