5 Underrated MCP Features That Make AI Clients Smarter

Krithika — Thu, 06 Aug 2026 05:14:12 +0000

Everyone's building MCP servers.

Most conversations focus on transports, authentication, OAuth, and exposing tools. Those topics are important, but while building a few MCP servers recently, I found myself appreciating a different part of the specification that doesn't seem to get nearly as much attention.

The interesting thing is that these aren't hidden APIs. They're already part of the Model Context Protocol specification or its official extensions.

None of the features below change what your tool does.

They change how clearly a client can understand and interact with your server.

1. Tool Annotations

This is the feature that inspired this post.

MCP lets you describe a tool's behavior through annotations such as readOnlyHint, idempotentHint, destructiveHint, and openWorldHint.

{
  "annotations": {
    "readOnlyHint": true,
    "idempotentHint": true,
    "destructiveHint": false,
    "openWorldHint": false
  }
}

Instead of only telling a client what a tool does, you're also telling it how it behaves.

A few examples:

readOnlyHint indicates that the tool does not modify its environment.
idempotentHint indicates that repeatedly calling a write tool with the same arguments has no additional effect on its environment.
destructiveHint distinguishes potentially destructive updates from additive ones.
openWorldHint indicates whether the tool may interact with an open world of external entities.

For example, a web search tool operates in an open world, while a tool that accesses a fixed local memory store operates in a closed domain.

These may look like simple booleans, but they can give clients useful context when planning execution, presenting tools to users, or designing confirmation flows.

There are a couple of details worth noting.

idempotentHint and destructiveHint are meaningful only for tools that are not read-only. Also, destructiveHint: false means the tool performs only additive updates.

Most importantly, these are hints, not security guarantees. Clients should not make security-sensitive decisions based on annotations from untrusted servers. Authentication, authorization, user consent, and deterministic safeguards still matter.

📖 MCP specification: Tools

2. Structured Tool Results

Many MCP tools still return only text.

Found 12 matching documents.

That works perfectly for humans.

Clients often benefit from receiving the underlying data in a structured form too.

MCP tools can return a JSON value through structuredContent.

{
  "structuredContent": {
    "documents": [
      {
        "title": "...",
        "url": "...",
        "lastModified": "..."
      }
    ]
  }
}

The value does not have to be an object. It can be any valid JSON value, including an array, string, number, boolean, or null.

Structured data can make it easier for clients to validate results, render interfaces, pass data into another workflow, or let models work with individual fields without parsing a natural-language response.

For backward compatibility, the specification recommends also returning the serialized JSON in a regular text content block.

One terminology distinction is useful here: MCP structuredContent is a structured tool result. It is not the same thing as LLM structured output or schema-constrained model generation.

📖 MCP specification: Structured Content

3. Output Schemas

If you're returning structured data, tell clients what it looks like.

When a client discovers tools through tools/list, it receives each tool's inputSchema.

A tool can also expose an outputSchema.

{
  "name": "search_documents",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string"
      }
    },
    "required": ["query"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "documents": {
        "type": "array"
      }
    },
    "required": ["documents"]
  }
}

This means the client can inspect the expected shape of structuredContent before invoking the tool.

If an output schema is defined, the server must return structured content that conforms to it. Clients are encouraged to validate the result.

This can support:

Response validation
Typed integrations
More predictable client-side handling
Richer interfaces
Clearer tool documentation

I like thinking of it this way:

Structured content tells clients what you returned. An output schema tells clients what to expect before you return it.

The two features complement each other nicely.

📖 MCP specification: Output Schema

4. Progress Reporting

Not every operation finishes in a second.

Think about indexing a repository, processing thousands of files, or running a large AI workflow.

Without progress reporting, users may be left staring at a loading spinner with no indication that work is continuing.

MCP supports optional progress notifications for long-running requests.

When a client wants progress updates, it includes a unique progressToken in the request metadata.

{
  "_meta": {
    "progressToken": "index-repository-123"
  }
}

The server may then send notifications/progress messages associated with that token.

{
  "method": "notifications/progress",
  "params": {
    "progressToken": "index-repository-123",
    "progress": 42,
    "total": 100,
    "message": "Indexing repository"
  }
}

The server is not required to send progress notifications, even when the client supplies a token. If it does send them, the progress value must increase with each notification. The total is optional when the amount of work is unknown.

Sometimes good UX isn't about making things faster.

It's about making the waiting less mysterious.

📖 MCP specification: Progress

5. Tasks

Some operations should not keep a request open until the work is finished.

MCP Tasks provide asynchronous execution for long-running operations such as CI pipelines, batch processing, external jobs, approval workflows, or model training.

Tasks are an official MCP extension rather than part of the core protocol. Both the client and server must declare support for the extension.

When a server decides that a supported request will be long-running, it can return a durable task handle instead of the final result.

The client can then:

Receive a task identifier
Poll the task using tasks/get
Resume polling after reconnecting
Provide requested input through tasks/update
Request cancellation through tasks/cancel
Retrieve the final result when the task completes

Tasks can also expose states such as working, input_required, completed, failed, and cancelled.

Polling is the default mechanism. Servers may additionally provide task notifications when supported.

This model is particularly useful when the underlying operation may outlive a network connection or pause while waiting for human input.

📖 MCP Tasks extension

Final Thoughts

It's easy to think of MCP as a protocol for exposing tools.

I think it's more than that.

It's also a protocol for helping clients understand and operate those tools.

A client that knows whether a tool modifies its environment, whether repeated calls have additional effects, what output shape to expect, how to consume structured data, and how to track longer-running work has much more context than one that receives only a name and description.

That's the part I find fascinating.

The protocol isn't just describing capabilities.

It's also describing behavior and execution patterns.

Some of these features take only a small amount of work to implement. Others, such as Tasks, require deeper support from both the client and server.

Still, they are worth understanding because they can lead to more predictable integrations and a better experience for users.

If you're building an MCP server today, it is worth spending a little extra time looking beyond tool names, descriptions, and input schemas.

Your clients may understand your server better, and your users may get a more transparent and reliable experience because of it.

I'd love to hear what other parts of MCP you think deserve more attention.

Dosa Therapy: The Comfort of Butter, Batter & Better Days

Krithika — Thu, 06 Aug 2026 04:26:04 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

I built Dosa Therapy, a colorful and playful landing page that treats dosa less like a meal and more like an emotional support system.

The idea came from how deeply comfort food is tied to mood. A crispy dosa, hot sambar, fresh chutney, and filter coffee can genuinely make a bad day feel slightly more manageable. So instead of creating a conventional restaurant landing page, I imagined a fictional therapy experience centered entirely around dosa.

The page takes users through the different layers of the dosa experience, from the batter and rice varieties to sambar, chutneys, dosa personalities, and mood-based recommendations.

Visually, I wanted the site to feel energetic, warm, and slightly chaotic in the best way. I avoided food photography and built the experience using bold geometric illustrations, expressive typography, vibrant colors, and playful animations.

Demo

🥞 Live Demo:
https://dosatherapy.vercel.app

💻 Source Code:
https://github.com/krxthx/dosa-therapy

Journey

I began with a much simpler idea: a bright landing page about dosa. But while exploring the concept, I realized that simply presenting dosa varieties and ingredients felt too similar to a restaurant menu.

That led to the idea of Dosa Therapy, a playful wellness-inspired brand where every mood has a corresponding dosa prescription.

One of the most important creative decisions was to use a fully illustrated visual style rather than realistic food images. I wanted the site to feel like its own tiny universe, with geometric dosas, animated chutney bowls, expressive ingredients, and sections that feel different while still belonging to the same visual system.

I particularly enjoyed building the sections around:

The anatomy of a comforting dosa meal
Different rice varieties used in dosa batter
Sambar and chutney as essential supporting characters
Popular dosa variants with their own personalities
Mood-based dosa recommendations
A filter coffee-inspired ending to complete the experience

The most challenging part was balancing all the colors, illustrations, typography, and movement without making the page feel visually overwhelming. I spent a lot of time adjusting spacing, section transitions, responsive layouts, and animation timing so the experience would still feel intentional.

I am especially proud that the final result does not look like a generic food landing page. It feels playful, culturally familiar, and very specifically about the joy of eating dosa.

Given more time, I would love to add a more interactive “Find Your Dosa” experience, richer scroll-based animations, and additional regional dosa varieties.

Because sometimes the solution is not deep breathing.

Sometimes it is dosa.

DEV Community: Krithika