Carson Rodrigues and Oysturn Vas catalog five MCP server architectural patterns to prevent LLM tool selection failures · Digg

Carson Rodrigues and Oysturn Vas catalog five MCP server architectural patterns to prevent LLM tool selection failures · Digg

Posts from X

Most Activity

VIEWS3.1KBOOKMARKS26LIKES45RETWEETS12REPLIES3

Rohan Paul@rohanpaul_ai

Very timely paper.

MCP servers need clear design patterns because LLMs get confused when too many tools or vague tools are shown.

This paper explains how MCP servers should be structured so LLM tools stay useful, safe, and manageable.

s MCP server design is not just normal API design, because the client is an LLM that chooses tools by reading plain-language descriptions.

It groups real MCP servers into 5 useful patterns, such as servers that expose data, run workflows, keep session state, combine many servers, or translate messy domain APIs.

The authors also warn about 4 common mistakes, especially giant all-purpose tools, vague tool descriptions, unsafe outside content, and slow tools that should return a job ID instead.

They tested the pattern labels on 54 extra servers, measured transport delay, and studied how tool accuracy changes as more tools are shown.

The key result is that too many visible tools hurt accuracy, with weaker models dropping below 90% between 10 and 15 tools.

Good MCP design is mostly about making the tool list small, clear, safe, and stable enough for LLMs to choose the right action.

----

Link – arxiv. org/abs/2606.30317

Title: "MCP Server Architecture Patterns for LLM-Integrated Applications"

3h3.1K4526

Bruce Martin@realbrucemartin

@omarsar0 shared names might save the industry from inventing the same wheel 15 times. pretty useful taxonomy.

1d3701

Vanar@Vanarchain

@omarsar0 Shared patterns and standards will make the MCP ecosystem much easier to build on.

13h1811

Eclipse 🌖@ECLresearch

@omarsar0 Standardizing the pattern taxonomies early prevents the fragmentation that usually kills dev tool adoption at scale. Curious how the data-flow pattern compares across the sample set.

1d337

Timur Yessenov@Timur_Yessenov

@omarsar0 I like the MCP taxonomy as a warning label. If one server is exposing resources, managing sessions, and adapting a workflow at once, you do not have “an MCP server”; you have three products sharing one set of keys.

1d189

Mikhail Rogov@i_mika_el

@omarsar0 shared names for MCP patterns are useful. without them every team invents same server shape again

1d176

Shinka - AI@ShinkaIoT

@omarsar0 Having a clear taxonomy for MCP server patterns is super helpful for AI teams to avoid reinventing the wheel.

1d162

Eriks Briedis@eriks_b

That tool-count result is interesting. Once Haiku sees roughly 10–15 tools, selection drops under 90%, so MCP needs the same curation you’d give a product screen. Show a small relevant set up front; everything else should fail loudly on bad inputs, with examples for parameters that aren’t obvious.

21h159

Nick Venturi@nickventuri

@omarsar0 reinventing the wheel is basically a developer hobby

1d143

Karthic Subramanian@thekarthic

@omarsar0 This is why the harness lens is useful.

Instead of treating “agent” as one thing, you can name the pieces: context/data access, evaluation, model calls, logs. That is usually where the real design work is.

17h129

𝕹𝖆𝖇𝖊𝖊𝖑 𝕶@TheNabeelKhan

@omarsar0 Names help, but the real win is per-pattern risk. An aggregating proxy inherits every upstream server's trust boundary; a session manager owns state you now have to secure and expire. Same shape, different failure modes. That's the next thing this taxonomy should make teams name.

1d87

Timofey@TimofeyKrava

@omarsar0 every team i have worked with rebuilt the stateful session server pattern from scratch. naming it does more for the ecosystem than any new framework would

1d57

Hesper AI@starhesper

@omarsar0 Five patterns, not five equal risks. The proxy aggregator holds auth for every downstream tool. One server, all keys, one misconfiguration. The taxonomy helps name the shape. The threat model should drive which shape you choose.

3h101

V0LYX@0xV0LYX

@omarsar0 always funny how teams recreate the same patterns in isolation

naming things really is the missing layer

1d24

Adel Bucetta@adelbucetta

@omarsar0 that's a good point about naming conventions, but don't be fooled that taxonomy won't save you from the real challenge: figuring out which patterns are relevant to your problem in the first place. most teams just end up with more questions than answers

1d11

Jasper 🌰@building BBX@bbxjasper

@rohanpaul_ai The 10-15 tool cliff matches what I keep hitting, and half the time it's not even the count, it's two tools whose descriptions overlap so the model just coin-flips between them. Tight non-overlapping naming does more than any routing layer.

3h10

Evan Hart@EvanHartAI

@omarsar0 A good benchmark would score evidence, not just output. Did it run the checks? Did it follow constraints? Did it leave enough context for a human to trust the result?

1d10

王小二@JokerFuFuFuFu

@omarsar0 The value is at the boundaries, not the names. Teams default to tool orchestration and bolt on session state + proxy aggregation later — exactly where auth and failure isolation break. Naming the shape forces the state/permission call before you're 3 tools deep.

19h9

TeutaAi@TeutaAi

@omarsar0 the shapes converged for me too, but each MCP server broke differently under a small model's handoff. that failure surface is the part no taxonomy names yet.

1d7

Shinka - AI@ShinkaIoT

@rohanpaul_ai This paper nails the challenge of tool explosion in LLMs; crucial insights for keeping agent tools useful and focused.

3h6