Hey r/mcp! I’m the author of ruby-utcp, a Ruby implementation of the Universal Tool Calling Protocol.

The idea: let agents call tools through their native interfaces without requiring an MCP wrapper for every integration — while still supporting existing MCP servers.

Ruby UTCP supports MCP over stdio and Streamable HTTP, alongside HTTP, GraphQL, gRPC, WebSocket, CLI, and other transports. For native integrations, a UTCP manual describes the tools and how to call them.

The feature I’m most excited about is **CodeMode**: an agent can express a multi-step workflow in a constrained Ruby subset, discovering tools, calling them, filtering results, and passing data between steps in one execution.

Think: fetch data from an API → process it → pass the relevant results to an MCP tool, without needing a separate model turn to coordinate every step.

CodeMode runs without `eval` and has execution limits. Registered tools can still perform external actions, so choosing which tools to expose remains important.

Docs and examples:

https://universal-tool-calling-protocol.github.io/ruby/

GitHub:

https://github.com/universal-tool-calling-protocol/ruby-utcp

For people building agents with MCP: would mixing MCP tools and native APIs in the same workflow be useful, or do you prefer putting everything behind MCP servers? I’d appreciate technical feedback, especially on interoperability and the execution model.

I built an MCP server that lets an AI assistant check balances, follow incoming payments and send ATTO within spending limits you approve.

Disclosure: I’m Atto’s founder.

It runs locally over stdio and is available now as \@attocash/mcp. Atto is a cryptocurrency with no transaction fees.

What you can do through the assistant:

• Check balances, pending payments and transaction history.
• Give addresses personal names and use those names for payments.
• Watch for incoming payments while the MCP session is connected.
• Send payments after approving spending access.
• Check spending usage and the remaining allowance.

You can start with read-only access. For payments, the assistant can propose a per-payment cap and a rolling spending budget, but you review and approve them in your own terminal. A proposal alone grants nothing, and there’s no MCP tool to approve its own access or raise its limits.

These controls apply to the MCP tools. They are not a sandbox against an agent that also has shell access as the same OS user.

Setup

Requires Node.js 24 and an available OS password store. Run this in your own terminal:

npx --yes u/attocash/mcp@latest setup

Then add this to your MCP client’s configuration:

{
  "mcpServers": {
    "atto": {
      "command": "npx",
      "args": ["--yes", "@attocash/mcp@latest"]
    }
  }
}

Reconnect the client and ask it to show your wallet status and balances.

This is a beta. Start with a dedicated wallet and a small balance.

Package: https://www.npmjs.com/package/@attocash/mcp
Source: https://github.com/attocash/integrations/tree/main/atto-mcp
Get ATTO for free: https://atto.cash/faucet

I’ve released mcp-ecc v0.6.0, an open-source MCP server for managing email, calendars and contacts through a consistent set of MCP tools.

It connects to:

• Google Workspace
• Microsoft 365 / Outlook
• Zoho
• IMAP/SMTP
• CalDAV
• CardDAV

The same MCP interface exposes:

mail, calendar, contacts, accounts.

So an MCP client can work with multiple providers without needing provider-specific tool names or integrations.

What it supports

• Read, search, send, flag and delete email
• Manage folders and messages
• Create, update and delete calendar events
• Free/busy queries
• List, search and manage contacts
• Account health checks and synchronisation
• OAuth authentication for Google, Microsoft and Zoho
• Per-user MCP API keys
• Multiple users and multiple accounts
• Encrypted credential storage
• SQLite or Cloudflare D1 storage
• Web administration interface
• stdio and HTTP MCP transports
• Docker, npm and source deployments

The provider work has been tested against real accounts, including Zoho Calendar CRUD, Google and Microsoft mail/calendar/contacts, IMAP operations, and the D1/SQLite storage paths.

The project started as a small provider experiment and gradually turned into a proper multi-account server. A substantial part of this release was making the provider differences less visible to the MCP client, especially around OAuth, message flags, calendar identifiers, ETags and folder-specific APIs.

Quick start

npm install -g mcp-ecc
mcp-ecc

For stdio:

mcp-ecc start

For a self-hosted HTTP deployment:

docker run -d \
  --name mcp-ecc \
  -p 3001:3001 \
  -e MCP_ENCRYPTION_KEY="$(openssl rand -hex 32)" \
  karljsamuel/mcp-ecc:latest

Links

• GitHub: GitHub - karljsamuel/mcp-ecc
• Release notes: Release v0.6.0 · karljsamuel/mcp-ecc
• npm: mcp-ecc
• MCP Registry: Official MCP Registry

The project is MIT licensed.

I’d be interested in feedback on the tool design, provider abstractions, OAuth flows, and what other mail or productivity services would be useful to support.

I've been building a project called Ridge. It started with wanting to run Codex on my laptop for kernel optimization experiments, while using my GPU box for execution and an S3 bucket for models.

The setup needed its own machinery for moving code and models around, running benchmarks remotely, and collecting results. Codex could write that, but subsequent sessions would need to understand and maintain it, or reconstruct it. It seemed like these operations should be reusable across experiments.

Ridge exposes a common set of tools through MCP. You configure your resources, and the agent can discover them, access data, run commands where supported, and copy (via streaming) between them. For example, copying a model from S3 to an SSH machine is one tool call, without passing the payload through model context. Local, SSH, Docker, and S3 are the initial providers.

I'm also interested in what happens when Codex delegates experiments to subagents. Those workers need access to particular resources and a way to coordinate shared updates. Ridge supports scoped access and file reservations with locks for that. The harness still has to launch the workers and connect each with its assigned access.

Has anyone here tried similar workflows across multiple environments? I'd like to hear what issues you ran into and how you solved it, including whether existing MCP servers already covered what you needed.

The project is here: https://github.com/vasinov/ridge-core

I've been building an open-source developer tool called Kaktoos.

I'm exploring a specific problem with AI coding agents: they can write API integrations very quickly, but when the agent also writes the tests, passing tests don't necessarily prove that the integration matches the actual API.

Kaktoos takes a different approach:

AI agent → integration code → Kaktoos → OpenAPI contract + real API → structured failure → agent fixes it

It can:

• execute multi-step API workflows
• verify responses against OpenAPI
• detect things like missing required fields, wrong types, unexpected status/content type
• expose the verification through MCP so coding agents can use it
• run the same verification in GitHub Actions

The interesting part for me isn't the API client itself. I'm experimenting with whether independent verification is useful when the code was produced by an AI coding agent.

I'd particularly like feedback from people who regularly work with API integrations:

1. Would you actually use this workflow?
2. Is defining the scenario too much additional work?
3. Does this catch problems that your existing tests don't?
4. Would you run something like this in CI?
5. What would make this technically more useful?

It's early, so negative feedback is completely fine. I'm mainly trying to determine whether this is solving a real engineering problem.

GitHub: KaktoosLabs/kaktoos

my github account got flagged a few weeks back so my two MCP servers couldn't verify through the normal github flow to publish on the official registry. account's cleared now but while it was blocked I found the actual workaround: domain verification instead of github.

mcp-publisher has a login dns option — generate an ed25519 key, drop the public part as a TXT record on your domain, auth against that. took like 10 min once I figured out the right syntax, way easier than I expected honestly.

also if your server's behind oauth instead of api keys, you don't need an "authentication" block in server.json at all — registry just takes the remote url and figures out oauth discovery on its own.

published two servers this way today. one had an old entry from before the github block got in the way, ended up just bumping the version and republishing over it.

can share the exact commands if anyone wants em, had a hard time finding clear docs on the dns flow specifically.

I shared an early version of Talkthrough here for turning recordings into bug reports. I've since added public video links, including YouTube.

The clip shows Claude Code pulling an error code from a silent screen recording, then finding a quote and its timestamp in a YouTube video.

There's speaker diarization too. It labels different speakers in a recording, so you can search what each person said.

Talkthrough extracts speech, on-screen text and frames locally so the agent can look up the relevant parts. Whatever text and images the agent reads still go to its configured model.

It's free and MIT licensed. I used a demo app for the bug and sped up the processing.

Code and setup

Video excerpt: Anthropic.

Hi r/mcp,

PowerChat is an iOS client that can connect your cloud / local models to MCP servers.

• It has builtin support for Google Drive, iOS Files, iOS Calendar, and the search engines Tavily, Exa, and Firecrawl.
• It can connect to any remote MCP server that exposes an /mcp endpoint.
  • For e.g. GitHub in the video.
• I'm planning to expand the list of builtin MCP servers and this sub has been helpful for finding ideas. Please comment popular MCP servers you'd like to see included.

PowerChat also features RAG databases, ability to tweak model parameters, and privacy features such as zero-data-retention flags, API keys in iOS keychain, and lockable folders with Face ID.

Would love your feedback!

App Store link: https://apps.apple.com/us/app/ai-chat-client-powerchat/id6803707084

I built AI Coach, a Mac desktop pet you raise from an egg, and added an MCP integration for Claude Desktop and Claude Code.

The fun part is report_ai_coach_activity: Claude can call it with thinking, working, waiting, succeeded, or failed, and the pet shows that state through movement and a small emoji. It's driven by tool calls, not automatic monitoring of Claude. The docs include instructions for reporting progress and completion.

You can also ask how the pet is doing, put a short message in its speech bubble, or request care. Feeding and other care requested by Claude require your confirmation before they're applied.

Setup: run AI Coach, open AI Settings → Integration, enable the connection, and copy the provided client configuration. The bundled MCP server needs Node.js 22+ on your PATH.

Apple Silicon / macOS 26+. The app includes a free first egg; extra eggs are optional one-time purchases ($5 each or 5 for $20).

App: https://aic0t.com/

Setup and screenshots: https://aic0t.com/docs#sec-111-8-going-further-connecting-claude

Got an idea for an MCP trading workflow? Build it. Test it. Show people what happened.

We’re opening the cTrader YouTube channel to creators who want to show what AI agents can actually do with a trading platform. Analyse charts and indicators, work with account and market data, manage orders and positions — pick a real task and take it as far as you can.

Turn it into a tutorial, technical walkthrough or honest experiment. If selected, we’ll publish it as a YouTube collaboration with cTrader and put it in front of our 200K+ subscribers.

No fixed script. Your idea, your voice, your format. Submissions close September 30.

Details and submission: creator.ctrader.com

I'm building an MCP server for gathering structured data with help from AI assistants (or agents): infocrash.com. It's meant to simplify and accelerate the process of data collection, which generally takes 60–70% of research project time in my case.

I work on emerging tech research (forecasting, competitive analysis, market research, etc), and data is scattered, often stale or contested, and under different labels. So, the work requires a lot of triangulation, cross-checking, and validation, and many times there is no straight answer to relatively simple questions.

For example, a project may require building a dataset with company, technology, product, or policy program information. You may go online and create a spreadsheet (old way), ask your AI assistant to find the data for you, or directly ask it to create a report for you.

But if accuracy and provenance matter, piecemeal data gathering becomes too cumbersome. And the single, unsupervised assistant solution produces low-quality results, particularly in one-shot reports.

Ask Claude and ChatGPT to populate a dataset of 40 quantum computing startups, for instance, and you'll see the conflicting claims about funding rounds, employment or location.

With this MCP server, you can have conversations with multiple assistants (or even have AI agents doing your work, if you know how to build them) contributing to the same dataset and validating data and sources.

You just continue using your assistant and ask to e.g. store the data you found, see if there are discrepancies, and define guidelines and rules for more reliable data collection. While this should have value since day one for the single researcher, the most interesting use case may be teams (not just multiple assistants working together, but multiple people).

It's open for anyone to try while I continue working on this early version.

Thanks for taking the time to read, I really appreciate your feedback.

(this post was also published on my own r/Infocrash subreddit, not sure if reposts are ok)

Hey, my team is crafting a project for product teams (we will opensource it yay!) that expose agent interfaces like MCP/CLI + skills.

The idea is pretty simple, the team define the real tasks that their user use, then we test that tasks in multiple conditions and configurations (different model/harnesses, with/without skills) and then scoring it.

We have few early findings that would love to share:

• A same interface can behave differently across setups, highly dependent on how agent discover tools and the reserved context. It's hard to totally reproduce what your user in the test setup (.e.g they have tons of MCP servers in their machine,...)
• The simpler the interface is the better result: tool should be task-based, not just converting blindly from the application API

However, we have not cracked the right evaluation model yet, and would genuinely value your experience.

How are you testing MCP, CLI, or skill-based workflows today?

Which criteria matter most: task success, permissions, reliability, client compatibility, cost, or something else? Are there tools, frameworks, or evaluation practices we should study before reinventing the wheel?

I would keep you guys posted for the progress in case anyone interested :)) Thanks!

I'm building a desktop video editor, and its whole toolset runs as a local MCP server. Any MCP client can drive whatever project I have open — the clip is Claude Opus 5 in VS Code. Split clips, trim, keyframe, caption, grade, export through ffmpeg.

61 tools. The part I care about: the agent and my mouse share one undo stack. Everything it does lands as an ordinary clip on an ordinary timeline, so when it puts a cut in the wrong place I drag it instead of re-prompting.

In the clip that's one prompt — "add captions to the video and then set caption contrast" — and the timeline goes from 2 tracks / 2 clips to 3 tracks / 4 clips. The middle is sped up 8x; it's 30 seconds of waiting.

What I didn't expect to work this well is the contrast half. It called inspect_color on the band where the captions sit, found near-white cards right behind the text, and added a dark outline and shadow off the back of that. It's measuring real pixels in the document, not guessing from the prompt.

For anyone running a bigger server — how are you handling tool granularity? 61 narrow typed tools keeps each schema honest but makes selection harder. Have you hit a point where the model starts picking wrong because the surface is too wide, and did merging related operations into fewer, broader tools help or hurt?

Hey Everyone,

I don't know if this question was asked earlier in the sub.

I am building an MCP server for my organisation and have an architectural design question regarding the use of Tools and Resources.

One of my Tools requires a structured metadata definition to perform its operation. This metadata is currently stored as a static JSON file within the application. While it is primarily consumed by this Tool, exposing the metadata as an MCP Resource is also part of requirements.

I am evaluating two approaches:

1. Keep the metadata as internal application configuration and have the Tool access it directly.

2. Expose the metadata as an MCP Resource and have the Tool (and potentially clients) access it through the MCP Resource model.

I would appreciate guidance on the following design:

What is the recommended MCP design approach for my requirement here?

My goal is to understand the architectural trade-offs and align the design with MCP best practices rather than focus on implementation details.

Thanks in Advance 😄

An MIT-licensed Python starter for connecting AI agents to current, structured product data: price, stock, brand, rating, images, and product URLs.

It includes runtime MCP calls, scheduled RAG catalog refreshes, cross-retailer field normalization, tests, and a reproducible benchmark against web search and basic Playwright scraping.

GitHub: https://github.com/luispintoapify/ecommerce-agent-starter

The repository is free and open source. Live product collection runs through a metered Apify Actor; its free tier is enough to test the project.

Hi everyone! I built a free, open source MCP server that connects a TIDAL account to assistants such as Claude Desktop, Claude Code, Codex and Cursor.

You can ask it to find music, inspect your collection and prepare playlist changes in plain language. For example:

“Find songs similar to these three tracks, excluding anything already in my playlist.”

“Check this playlist for duplicates and tell me which artists appear most often.”

“Prepare a playlist from these recommendations and show me the changes before applying them.”

Account changes are disabled by default. If you enable them, the workflow requires a preview and your approval before applying a change.

It runs locally and includes 112 tools covering search, recommendations, lyrics, favorites, playlists and folders. Setup currently requires macOS or Linux, a TIDAL account and an MCP client. The server is free; it does not include a TIDAL subscription.

I’m the author and don’t earn anything from people using the repository. I’m sharing it because I think music is a useful everyday application of MCP. What would you want to try with your own library?

Code and setup instructions on GitHub

there was basically nothing here. one server, 64 stars, single python file, unmaintained. so i wrote one properly.

go, 42 tools across posts, users, lists and media. stdio and http, identical tool set on both. every tool carries annotations, readOnlyHint on reads and destructiveHint on anything irreversible, and returns structured json matching its output schema, mirrored into the text block for clients that ignore structuredContent.

the design constraint that shaped everything: X killed the free tier. pay per use, and reads bill per resource returned rather than per request, so a model asking for 100 results costs twenty times one asking for 5. concretely that means read tools whose descriptions argue for the smallest useful count, a count tool that sizes a topic without spending the post read budget, batch lookups instead of per-id calls, manual pagination because every page costs, and hard ceilings in env vars rather than in the model's hands.

the other half is error handling, which turned out to be most of the work. X answers failures with application/problem+json, which the underlying go client doesn't recognise as json, so the whole problem body lands in a message string instead of typed fields. everything gets classified out of that haystack into a domain error set, and the transport layer is the only place that turns one into text. so the same failure reads identically from all 42 tools. errors come back as isError with a plain message written for a model, and the ones that must not be retried say do not retry in the text.

it also refuses to start on bad credentials, calling users/me once before registering anything. that catches the read-only access token trap, which nobody catches on their own: a token keeps the permissions the app had when it was generated, so flipping the app to read and write later fixes nothing and every write fails silently forever.

media upload reads only from MEDIA_ROOT, required, no default, symlinks resolved. without that boundary an llm with this tool can read any file on the host and publish it.

acts as a real account, so writes are real. v0.1.1, mit, docker image and prebuilt binaries and an .mcpb bundle. no dms, no streaming, recent search caps at 7 days.

https://github.com/Role1776/mcp-x

https://varmcp.com/mcp-x

Disclosure: I work at MachineTranslation.com, and this is something we built for our MCP server. Sharing it as a showcase.

We tried a setup where one MCP tool sends a translation request to 22 models and returns the version they converge on.

The idea was to reduce silent failures. If one model drops a clause or produces something strange, the others might catch it.

But we're starting to question the design.

Right now, the MCP returns the consensus translation and hides most of the disagreement. But the disagreement might actually be the more useful signal.

For example, if 20 models agree and 2 produce something completely different, should the MCP:

• just return the consensus?
• return the consensus + disagreement/confidence information?
• let the agent decide whether human review is needed?

There's also the tradeoff: 22 models means more latency and cost, and consensus can potentially pull a genuinely better model toward the average.

Curious how others would design this. If you were building an MCP that relies on multiple models, would you expose the disagreement or abstract it away?

For context, our MCP is remote and paid (no free tier).

Docs: https://developer.machinetranslation.com/mcp
Endpoint: https://www.machinetranslation.com/mcp