{"id":4018,"date":"2026-07-10T09:31:16","date_gmt":"2026-07-10T09:31:16","guid":{"rendered":"https:\/\/www.infragistics.com\/blogs\/?p=4018"},"modified":"2026-07-10T09:37:36","modified_gmt":"2026-07-10T09:37:36","slug":"mcp-vs-rag-docs-retrieval","status":"publish","type":"post","link":"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-docs-retrieval","title":{"rendered":"MCP vs RAG: 100-Query Benchmark Reveals the Costly Winner"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\" id=\"abstract\">Abstract<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>MCP vs RAG<\/strong> is the architectural question behind this post: should an AI documentation agent retrieve context from a static vector index, or query documentation and API metadata through tool calls at request time? <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We benchmarked both approaches head-to-head &#8211; a Model Context Protocol (MCP) server <a href=\"https:\/\/modelcontextprotocol.io\" data-type=\"link\" data-id=\"https:\/\/modelcontextprotocol.io\" rel=\"noopener\">[2]<\/a> against an AWS Bedrock vector Knowledge Base (RAG) <a href=\"https:\/\/docs.aws.amazon.com\/bedrock\/latest\/userguide\/knowledge-base.html\" rel=\"noopener\">[3]<\/a> &#8211; across 100 matched developer queries spanning component how-tos, exact API\/type lookups, theming, feature-freshness checks, and code generation, using the same Claude model as the orchestrating LLM in both arms. MCP produced the higher-confidence answer in 52% of head-to-head comparisons versus 38% for RAG (10% ties), with its largest wins concentrated in exact API interface lookups (+50 to +67 confidence points), at a cost of 2.5x higher latency and roughly 36x higher per-query spend. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Architects deciding between these two retrieval strategies for an internal documentation agent will find, below, the specific query categories where each wins, why the cost gap exists, and a decision matrix for making the call. This post summarizes the full research report for MCP vs RAG <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>; the complete methodology, raw benchmark tables, and query-by-query data there.<\/p>\n\n\n<div class=\"igm-markdown-block\" data-markdown=\"&gt;  **TL;DR:** MCP vs RAG: MCP-based retrieval beats a vector-indexed RAG on grounding and citation depth, especially for exact API surface questions, but it runs roughly 11 tool-call turns per query instead of one embedding lookup - 2.5x slower and 36x more expensive. Use it for a lower-volume, correctness-critical internal tool; keep RAG for high-volume, latency-sensitive, customer-facing chat.\">\n                <div class=\"igm-markdown-content\"><\/div>\n                <noscript><pre>&gt;  **TL;DR:** MCP vs RAG: MCP-based retrieval beats a vector-indexed RAG on grounding and citation depth, especially for exact API surface questions, but it runs roughly 11 tool-call turns per query instead of one embedding lookup - 2.5x slower and 36x more expensive. Use it for a lower-volume, correctness-critical internal tool; keep RAG for high-volume, latency-sensitive, customer-facing chat.<\/pre><\/noscript>\n            <\/div>\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2 id=\"table-of-contents\">Table of Contents<\/h2><nav><ul><li><a href=\"#abstract\">Abstract<\/a><\/li><li><a href=\"#introduction\">Introduction<\/a><\/li><li><a href=\"#methodology\">Methodology<\/a><\/li><li><a href=\"#benchmarks\">Benchmarks<\/a><\/li><li><a href=\"#findings\">Findings<\/a><\/li><li><a href=\"#decision-matrix-mcp-vs-rag-by-scenario\">Decision Matrix: MCP vs RAG by Scenario<\/a><\/li><li><a href=\"#code-examples\">Code Examples<\/a><\/li><li><a href=\"#conclusion-mcp-vs-rag-the-verdict\">Conclusion: MCP vs RAG, the Verdict<\/a><\/li><li><a href=\"#references\">References<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"introduction\">Introduction<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ignite UI ships four framework variants &#8211; Angular, React, Blazor, Web Components &#8211; each with an independent API surface, and its documentation changes on every minor release. The AI Agent Gateway behind Ignite UI&#8217;s support and docs chat originally answered from a Bedrock Knowledge Base: a vector index built from periodic documentation snapshots. That architecture has one structural weakness &#8211; hallucinations caused by index staleness. A property shipped in a patch release doesn&#8217;t exist in the vector store until the next re-index job runs, and the model has no signal that the gap exists. It just answers confidently from what it has.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The alternative tested here replaces the vector index with an MCP server from the Ignite UI CLI MCP exposing four tools &#8211; <strong>search_docs, get_doc, search_api, get_api_reference<\/strong> &#8211; that query documentation and generated API reference at request time. Claude drives this as an agentic loop: decide which tool to call, read the result, repeat until there&#8217;s enough grounding to answer.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Most MCP vs RAG comparisons in the wild are qualitative &#8211; &#8220;it feels more accurate.&#8221; This post is built from a fixed 100-query set, an LLM-judge scoring rubric, and per-query cost and latency telemetry pulled from both pipelines&#8217; production logs, documented in full in the underlying research report <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"methodology\">Methodology<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The MCP vs RAG comparison below is built on a fixed, repeatable test harness. Full detail &#8211; exact versions, scoring weights, and excluded scope &#8211; is in the research report <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>; the short version:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Systems under test<\/strong>: AWS Bedrock Knowledge Base (single-turn vector retrieval) vs. an MCP server (multi-turn tool-use loop, capped at 20 turns) &#8211; same Claude model family driving both<\/li>\n\n\n\n<li><strong>Query set<\/strong>: 100 queries across component how-to, API\/type lookups, theming\/SCSS, recent-feature freshness, and code generation.<\/li>\n\n\n\n<li><strong>Scoring<\/strong>: a composite 0\u2013100 confidence score per answer, weighted across Retrieval Relevance, Answer Clarity, and Answer Grounding, judged by the same LLM rubric on both arms.<\/li>\n\n\n\n<li><strong>Head-to-head<\/strong>: the higher-scoring answer wins unless the gap is \u22641 point (tie), evaluated on 96 of the 100 queries with valid scores on both sides.<\/li>\n\n\n\n<li><strong>Explicitly out of scope<\/strong>: concurrent-session throughput (this ran single-session, sequential) and a direct measurement of how stale the RAG snapshot was at test time.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity is-style-default\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"benchmarks\">Benchmarks<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The MCP vs RAG numbers below are all figures from the 100-query run, single sequential session, no concurrent load <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>.<\/p>\n\n\n\n<figure class=\"wp-block-table is-style-stripes\"><table class=\"has-fixed-layout\"><thead><tr><th>Metric<\/th><th>Bedrock RAG<\/th><th>Ignite UI CLI MCP<\/th><th>Delta<\/th><\/tr><\/thead><tbody><tr><td>Avg total latency<\/td><td>12,715 ms<\/td><td>31,932 ms<\/td><td>+151%<\/td><\/tr><tr><td>Avg time to first token<\/td><td>&nbsp;6,314 ms<\/td><td>29,372 ms<\/td><td>+365%<\/td><\/tr><tr><td>Avg cost per query<\/td><td>$0.0047<\/td><td>$0.1691<\/td><td>+3500%<\/td><\/tr><tr><td>Avg confidence (composite)<\/td><td>70.3<\/td><td>73.9<\/td><td>+3.6 pts<\/td><\/tr><tr><td>Avg citations per answer<\/td><td>2.2<\/td><td>4.5<\/td><td>+2.3<\/td><\/tr><tr><td>Head-to-head win rate<\/td><td>38%<\/td><td>52%<\/td><td>10% ties<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\"><em>Limitation: this measures single-session, cold-cache latency and cost. It does not measure how prompt-caching economics shift under sustained concurrent multi-user load, which would likely lower MCP&#8217;s effective per-query cost in production.<\/em><\/figcaption><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"findings\">Findings<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The MCP vs RAG gap is not uniform across query types &#8211; it concentrates in specific categories.<br><br><strong>1. MCP wins big on exact API surface lookups, not general how-to questions.**<\/strong> Asking for the full property list of a TypeScript interface or event-args class is where RAG most often fails outright &#8211; two of the largest MCP wins in the dataset were interface-definition questions where RAG&#8217;s answer amounted to &#8220;I don&#8217;t have the complete information,&#8221; while MCP retrieved the complete member list with types and optionality markers <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>2. Tool-call turn count predicts MCP&#8217;s latency almost linearly.<\/strong> Queries resolved in 2\u20134 turns finished in 7\u201311 seconds, on par with RAG. Queries needing 18\u201320 exploratory turns took 45\u201375 seconds &#8211; one loading-overlay how-to burned 21 tool calls and 75 seconds because the agent kept re-searching instead of recognizing it already had enough to answer <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>3. MCP&#8217;s grounding advantage is structural, not just topical relevance.<\/strong> Of the three scored sub-components, Answer Grounding &#8211; whether claims are actually backed by retrieved content &#8211; showed the largest gap in MCP&#8217;s favor. Structured API type data is harder to hallucinate against than free-text prose that has to be paraphrased <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>4. RAG wins on stable, well-documented styling and theming content.<\/strong> The largest RAG wins in the dataset were all styling questions, where dense embedding search matched a thin documentation page more directly than MCP&#8217;s keyword-oriented search &#8211; proof that MCP retrieval isn&#8217;t automatically better when the underlying docs are hard to search rather than stale <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>5. The &#8220;recently added feature&#8221; category didn&#8217;t show a decisive MCP advantage at this sample size.<\/strong> Individual queries favored MCP, others favored RAG &#8211; directionally consistent with the staleness hypothesis but not statistically conclusive with only 15 queries in that category <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Taken together, these five findings are why the MCP vs RAG decision can&#8217;t be settled with a single aggregate score.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"decision-matrix-mcp-vs-rag-by-scenario\">Decision Matrix: MCP vs RAG by Scenario<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Use this table to resolve the MCP vs RAG question for your own workload by matching it to the closest scenario row.<\/p>\n\n\n\n<figure class=\"wp-block-table is-style-stripes\"><table class=\"has-fixed-layout\"><thead><tr><th class=\"has-text-align-left\" data-align=\"left\">Scenario<\/th><th class=\"has-text-align-left\" data-align=\"left\">Bedrock RAG<\/th><th class=\"has-text-align-left\" data-align=\"left\">Ignite UI CLI MCP<\/th><\/tr><\/thead><tbody><tr><td class=\"has-text-align-left\" data-align=\"left\">High query volume, cost-sensitive (support chat)<\/td><td class=\"has-text-align-left\" data-align=\"left\">\u2705 ~36x cheaper, sub-15s typical latency<\/td><td class=\"has-text-align-left\" data-align=\"left\">\u274c $0.17\/query and 30s+ average is uneconomical at scale<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\">Exact API\/type reference lookups (IDE assistant, SDK bot)<\/td><td class=\"has-text-align-left\" data-align=\"left\">\u26a0\ufe0f Fails or hedges when the interface isn&#8217;t in the snapshot<\/td><td class=\"has-text-align-left\" data-align=\"left\">\u2705 Retrieves complete type definitions<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\">Latency-sensitive, streaming chat UI<\/td><td class=\"has-text-align-left\" data-align=\"left\">\u2705 TTFT ~5\u20136s median<\/td><td class=\"has-text-align-left\" data-align=\"left\">\u274c TTFT ~29s median unless intermediate tool status streams to the client<\/td><\/tr><tr><td class=\"has-text-align-left\" data-align=\"left\">Stable, well-documented styling\/theming questions<\/td><td class=\"has-text-align-left\" data-align=\"left\">\u2705 Dense embedding search matches thin doc pages well<\/td><td class=\"has-text-align-left\" data-align=\"left\">\u26a0\ufe0f Keyword search can miss under-indexed pages<\/td><\/tr><\/tbody><\/table><figcaption class=\"wp-element-caption\"><em>*Guidance: if your workload mixes both patterns, route by query intent &#8211; API\/type lookups to MCP, general how-to and styling to RAG &#8211; rather than picking one architecture for everything <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a>.*<\/em><\/figcaption><\/figure>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"code-examples\">Code Examples<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Whatever side of the MCP vs RAG decision you land on, two implementation details are worth encoding directly if you deploy MCP: bound the tool-call loop, and don&#8217;t let a zero-result tool call produce a confident answer.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Bounding the multi-turn loop<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Finding 2 showed unconstrained queries hitting 18\u201320 turns. An explicit budget with an early-exit instruction caps the p95 tail without hurting queries that resolve quickly.<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"typescript\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">async function runMcpQuery(question: string, maxTurns = 10) {\n  let turns = 0;\n  let messages = [{ role: \"user\", content: question }];\n\n  while (turns &lt; maxTurns) {\n    const response = await claude.messages.create({\n      model: MODEL,\n      tools,\n      messages,\n      system:\n        \"If you have already retrieved content sufficient to answer \" +\n        \"with grounded confidence, answer now instead of issuing another tool call.\",\n    });\n\n    if (response.stop_reason !== \"tool_use\") return response;\n\n    messages.push({ role: \"assistant\", content: response.content });\n    const toolResults = await Promise.all(\n      response.content.filter((b) => b.type === \"tool_use\").map(executeTool)\n    );\n    messages.push({ role: \"user\", content: toolResults });\n    turns++;\n  }\n\n  throw new Error(`MCP query exceeded ${maxTurns} turns without resolving`);\n}<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Refusing to answer on zero-grounding<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Finding 4&#8217;s styling losses share a root cause: tools return no useful match, and the model answers anyway. Detecting that and forcing an explicit &#8220;insufficient grounding&#8221; response closes the gap. a small guardrail that matters regardless of which side of the MCP vs RAG split your production traffic falls on.<\/p>\n\n\n\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"typescript\" data-enlighter-theme=\"\" data-enlighter-highlight=\"\" data-enlighter-linenumbers=\"\" data-enlighter-lineoffset=\"\" data-enlighter-title=\"\" data-enlighter-group=\"\">function checkGrounding(toolResults: ToolResult[]): boolean {\n  const hasContent = toolResults.some((r) => r.matches?.length > 0);\n  if (!hasContent) {\n    throw new InsufficientGroundingError(\n      \"No documentation or API matches found; escalate or return explicit no-answer.\"\n    );\n  }\n  return hasContent;\n}<\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"conclusion-mcp-vs-rag-the-verdict\">Conclusion: MCP vs RAG, the Verdict<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Use MCP<\/strong> when the workload is dominated by exact API\/type reference questions, documentation changes faster than a re-index cycle can track, and query volume is low enough that $0.17\/query and ~32s average latency are acceptable &#8211; an internal SDK reference assistant or IDE copilot fits this profile.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Use RAG<\/strong> when query volume is high, latency has to stay under a few seconds, and the underlying content is stable prose (styling guides, conceptual how-tos) that a vector index already retrieves well.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Default to a hybrid<\/strong> if your traffic mixes both intents &#8211; the two systems&#8217; advantages sit in nearly opposite query categories rather than one dominating uniformly, which makes intent-based routing more useful than an either\/or architectural choice on the MCP vs RAG question. The MCP approach can be also utilized for a &#8220;deeper thinking&#8221; mode &#8211; for additional questions in an existing session where the initial RAG based answer wasn&#8217;t able to resolve the user&#8217;s question.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The open question this post doesn&#8217;t answer: whether MCP&#8217;s cost and latency profile improves under sustained concurrent load with cache reuse across similar questions. That requires a concurrent-load test the current dataset can&#8217;t answer &#8211; see the full report <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">[1]<\/a> for the complete list of exclusions.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you&#8217;re running your own MCP vs RAG evaluation, the query-category breakdown above is the fastest way to predict which architecture your workload favors before you spend a single dollar on infrastructure.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"references\">References<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>## References<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[1] &#8220;MCP vs RAG: AI Documentation Retrieval Benchmark,&#8221; research report, <a href=\"https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark\">https:\/\/www.infragistics.com\/blogs\/mcp-vs-rag-benchmark<\/a>, Ignite UI, July 2026.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[2] Model Context Protocol specification, Anthropic, <a href=\"https:\/\/modelcontextprotocol.io\" rel=\"noopener\">https:\/\/modelcontextprotocol.io<\/a><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">[3] AWS Bedrock Knowledge Bases documentation, Amazon Web Services, <a href=\"https:\/\/docs.aws.amazon.com\/bedrock\/latest\/userguide\/knowledge-base.html\" rel=\"noopener\">https:\/\/docs.aws.amazon.com\/bedrock\/latest\/userguide\/knowledge-base.html<\/a><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>MCP vs RAG: MCP-based retrieval beats a vector-indexed RAG on grounding and citation depth, but it&#8217;s slower and more expensive. Use it for correctness-critical requests; keep RAG for high-volume, latency-sensitive ones.<\/p>\n","protected":false},"author":178,"featured_media":4017,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[141,139,140],"tags":[136,132,134,137,20,133,135,83,138,130,131],"class_list":["post-4018","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ignite-ui-cli-mcp","category-ai-engineering","category-architecture","tag-ai-agent-architecture","tag-aws-bedrock","tag-claude","tag-developer-tools","tag-ignite-ui","tag-knowledge-base","tag-llm-benchmarking","tag-mcp","tag-model-context-protocol-2","tag-rag","tag-retrieval-augmented-generation"],"_links":{"self":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/4018","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/users\/178"}],"replies":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/comments?post=4018"}],"version-history":[{"count":17,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/4018\/revisions"}],"predecessor-version":[{"id":4041,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/4018\/revisions\/4041"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/media\/4017"}],"wp:attachment":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/media?parent=4018"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/categories?post=4018"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/tags?post=4018"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}