# Accept Language Parser MCP > Parse Accept Language By taking a raw HTTP header string and returning an ordered, deterministic list of language preferences with their quality weights. This correctly follows RFC 7231 standards, telling your agent exactly which languages a user prefers for global routing or content negotiation. ## Overview - **Category:** productivity - **Price:** Free - **Tags:** http-headers, localization, language-detection, rfc-compliance, parsing, web-standards ## Description When you build an application that serves users globally, figuring out the right language is non-negotiable. You can't just guess based on IP location. This MCP reads the raw 'Accept-Language' header—that string of codes and quality weights sent by a browser—and turns it into a clean list. It processes complex inputs like "en-US,pt-BR;q=0.9,fr;q=0.8" correctly, respecting every quality score (or q-factor) exactly as the HTTP standard dictates. The result is a prioritized sequence of languages, with the user's top choice listed first. This eliminates guesswork from your routing logic. If you're using Vinkius for other services, this MCP ensures language detection is always rock solid and compliant. ## Tools ### parse_accept_language Passes a raw Accept-Language header string and returns an ordered list of user language preferences with their quality weights. ## Prompt Examples **Prompt:** ``` Parse this Accept-Language header: en-US,pt-BR;q=0.9,fr;q=0.8 ``` **Response:** ``` Preferred: en-US (q=1) > pt-BR (q=0.9) > fr (q=0.8) ``` **Prompt:** ``` What is the user's preferred language from: de,en-GB;q=0.7,ja;q=0.3 ``` **Response:** ``` Preferred: de (q=1, German) ``` **Prompt:** ``` How many languages does the browser support based on this header: zh-CN,zh;q=0.9,en;q=0.8,ko;q=0.7,ar;q=0.6 ``` **Response:** ``` 5 languages detected: zh-CN, zh, en, ko, ar ``` ## Capabilities ### Determine Language Priority Reads a raw header string and outputs the user's preferred languages in order of importance. ## Use Cases ### A global e-commerce site needs to load the checkout page. The client sends a header listing English and Spanish, but with different priorities. Instead of defaulting to US English, your agent uses this MCP to see that the user actually prefers French (q=0.8) over Spanish (q=0.7), ensuring the correct localized content loads for checkout. ### A multi-region API gateway handles requests. The API needs to decide which version of its documentation endpoint to expose. By passing the header through this MCP, the agent gets a clear list that prioritizes Japanese (q=1) over Chinese (q=0.9), routing the request immediately to the correct backend service. ### A content management system is serving localized articles. The CMS receives requests from various clients. Using this MCP, the agent determines that while German and English are listed, the user's true preference is Italian (q=0.85). The system then pulls and serves the article in high-quality Italian. ### Building a complex microservice chain. A series of services must process incoming data according to language rules. This MCP provides the definitive, ordered list upfront, allowing subsequent services (like validation or database calls) to operate only on guaranteed preferences. ## Benefits - Stops guesswork in global routing. Instead of making assumptions, your agent gets a guaranteed priority list based on strict HTTP standards. - Handles complex inputs correctly. It accurately parses quality weights (q-factors) like `pt-BR;q=0.9`, which simpler parsers ignore or misinterpret. - Saves time building i18n logic. You don't need to write custom RFC 7231 compliance code; this MCP handles the heavy lifting for you. - Improves user experience across regions. By knowing the true preference, you serve content in the language the user actually asked for. - Works with any agent environment. Connect your logic via Vinkius to use this reliable data source from Claude, Cursor, or Windsurf. ## How It Works The bottom line is you get a reliable sequence of language preferences that your code can use immediately for routing or content selection. 1. You pass the full 'Accept-Language' HTTP header value to your agent. 2. The MCP processes that string, accurately calculating and sorting all quality weights (q-factors) against the RFC 7231 standard. 3. Your agent receives a clear list: the languages sorted from most preferred to least preferred. ## Frequently Asked Questions **How does parse_accept_language handle multiple quality weights?** It processes them accurately according to RFC 7231. It correctly sorts the languages based on their assigned 'q' factor, making sure the highest weighted language is listed first. **Does parse_accept_language support only US English headers?** No. This MCP supports all recognized HTTP Accept-Language formats globally and reliably parses weights for any combination of locale codes. **Is this better than just looking at the first language listed?** Yes, absolutely. The first listed language might not be the most preferred; it only means it's listed first. This MCP determines true preference based on calculated quality weights. **Can I use parse_accept_language with my existing i18n logic?** You can. By feeding this MCP the raw header, you get a guaranteed priority list that should slot right into your current decision-making process for content delivery. **What happens if I pass malformed data to parse_accept_language?** It handles invalid headers gracefully. The tool won't crash your process; instead, it returns a clear error or the valid subset of languages found. This built-in validation keeps your global routing agent stable even when receiving bad HTTP data. **Is parse_accept_language performant enough for high-volume API calls?** Yes, it's highly optimized for speed and low latency. Because it's a dedicated parsing function, you won't encounter bottlenecks common with general string processing. You can expect near-instantaneous results even when running through hundreds of headers per second. **How do I integrate parse_accept_language into my existing backend service?** You simply call it as a function, passing the raw Accept-Language header string. It's built to drop right into standard environments like Python or Node without requiring complex setup steps or custom middleware. **What result does parse_accept_language return if the header is completely missing?** The function handles null, empty, or absent inputs by returning a predictable, empty ordered list. This reliable behavior allows your agent to execute a safe fallback logic without ever encountering a runtime error. **What is a quality weight (q-factor)?** A value from 0 to 1 indicating preference. `q=1` (default) is highest priority. `q=0` means the language is explicitly not accepted. **Does it handle regional subtags?** Yes. `pt-BR` is parsed as code=pt, region=BR. `en-US` as code=en, region=US. The region is separated from the language code automatically. **What if no quality value is specified?** Languages without an explicit q-value default to q=1 (highest priority), following the HTTP specification.