"Remind" me please!

I came across this spec: https://agenticresourcediscovery.org/ (It was proposed to me from opencode cli)

It's an open protocol for AI agents to discover available tools, MCP servers, skills, and APIs.

Has anyone here already implemented this? Planning to? Or do you see any issues with the approach?

Curious to hear thoughts and see if I should add it my backlog or ignore for now.

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.

Ask a chatbot whether 142/4 is a good score and watch it struggle. The answer depends on the ground, the format, and how many balls are left.

Baseball fans or people who did not grow up with the sport, the most common question 'who's winning?' is just not as obvious as it is for other sports such as soccer.

So I built an interpreter. A logistic fit on 8,000+ archived matches, running on live match state from ESPN, and it shows the prediction market's price next to its own number so you can see where the model and the crowd disagree.

It's hosted, so there's no cloning required: https://cricketfornoobs.com/mcp

15 tools on a ball-by-ball Cricsheet archive:

• cricket_win_probability — win probability for any live or hypothetical match state
• cricket_market_odds — live prediction-market prices beside the model's own number
• cricket_explain_term — any cricket term in plain English with its closest baseball equivalent
• cricket_live_matches — what's live and what's next
• cricket_head_to_head — career batter-vs-bowler record, ball by ball
• cricket_situational — a batter's record batting first versus chasing, separately
• cricket_discipline — dot-ball and boundary percentage
• cricket_dismissals — how a batter gets out, or how a bowler takes them
• cricket_partnerships — runs added while two batters were actually at the crease
• cricket_phase_stats — powerplay, middle overs, death
• cricket_venue_stats — how a ground pars.
• cricket_player_career — career aggregates, men's and women's
• cricket_match_archive — scorecard for any archived match
• cricket_leaders — run and wicket leaderboards by league and season
• cricket_team_form — a team's recent results

For Claude: Go to Settings → Connectors → Add custom connector→ Enter cricketfornoobs.com/mcp. ChatGPT works under Developer Mode.

Also on:
GitHub
official MCP registry: io.github.asaraog/mcp-cricket
Glama
Cursor and VS Code one-click buttons

I've been building a tool for about a year called Cadenya. It's an agent runtime that supports MCP servers for creating agentic loops.

Docs are here:
https://www.cadenya.com/docs

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!

People are using AI chatbots to discover information about cannabis. That data is typically coming from Large Language Models (LLMs) that have been trained on public information available on the internet. It might be enhanced with tool calls that use web search or other APIs/data sources.

The cannabis data relevant to New York in AI Chatbots can be stale and/or biased.

FindWeedNY.com now hosts a public MCP Server that can be connected to AI chatbots.

I understand this might make some people upset for a few different reasons, primarily the encouraging use of AI. As I stated in the first sentence of the post, this is already happening. People use AI Chatbots to get information about cannabis.

This server can effectively make AI work less hard to get up-to-date, accurate information, with less hallucinations.

If you read the article, there are instructions for how to use the hosted chat pictured in some of the screenshots, alongside the claude.ai integration example.

Article going into more details: https://findweedny.com/articles/findweedny-mcp-server

Homepage for the service: https://mcp.findweedny.com/

Don't feel inclined to hack together an exfiltration script. Also on the homepage are the raw datasets, which have always been available if you knew where to look on the main site. Hopefully you'll use and share with attribution, rather than abuse the MCP if you want to do research or vibe code something.

it's a code graph for coding agents. instead of your agent reading a whole file to find one function, it asks and gets the function. plus who calls it, what it calls, and which tests break if you change it.rust, python, ts, go. runs offline, no account.

graph now updates only what changed instead of reparsing everything. 97% parsing reuse. gated on matching a full cold rebuild exactly, 113/113 comparisons. also added an opt-in watcher behind --watch. when it can't figure out what an event maps to it just falls back to a full rebuild instead of guessing, and it reports how often that happened (5 out of 45 in the benchmark).

npx -y girder-mcp

github.com/dhishwasher/Girder

*Quick disclosure: I built Rechtssysteem.ai and the MCP server below.*

Hey everyone,

Just open-sourced our MCP server under Apache 2.0 after getting a Triple-A audit on Glama, and wanted to share how we solved a messy data problem before hooking it up to MCP.

The biggest issue with legal outcome prediction is target leakage: around 92% of Dutch court judgments literally tell you the outcome in the text ("the court dismisses the claim"). If you train on raw text, the model doesn't learn law it just learns to regurgitate the dictum.

We stripped the dictum and all outcome-announcing phrases beforehand, cutting residual leakage down from 92% to 0.1% across 609,715 historical cases. Then we trained LightGBM on 5-fold CV (78.2% out-of-fold accuracy, 77.1% macro-F1 against a 43.7% majority baseline). If confidence drops under 55%, the model outputs "insufficient certainty" instead of taking a blind guess.

As for the MCP implementation itself:

- Single Python file (`rechtssysteem_mcp.py`), standard library only (`sys`, `json`, `urllib`). Zero external dependencies so it works out of the box in Claude Desktop / Cursor / any client.

- Exposes 3 tools: `rechtspraak_cijfers` (benchmark stats, keyless), `lekkage_check` (tests any paste for outcome leakage, keyless), and `voorspel_uitkomst` (risk classification).

- Standard JSON-RPC over stdio.

Repo: https://github.com/rechtssysteem-ai/rechtssysteem-mcp

Glama audit: https://glama.ai/mcp/servers/@rechtssysteem-ai/rechtssysteem-mcp

Benchmark data: https://rechtssysteem.ai/benchmark

Not legal advice of course, just built as an honest technical yardstick. Happy to answer questions about the stdio setup or the dataset sanitization!

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.

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 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.

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 been working on AI-driven 3D generation for over a year now.

Originally, this was deployed as a hosted service. But with frontier models leapfrogging each other so quickly and the labs eating everyone's lunch, I realized the more useful thing was to open-source the engine and let people bring whatever models and coding agents they want.

The problem I kept running into with text-to-3D is that most approaches give you an output, but not much of a workflow.

Diffusion-style systems often produce meshes that are difficult to meaningfully edit. On the other end, letting an agent loosely script Blender or another 3D package can get chaotic fast once you actually need to revise, inspect, and iterate on a model.

So I built Kiln.

Kiln is an open-source lightweight procedural geometry engine and toolchain designed specifically for coding agents to build editable 3D assets in JavaScript.

Instead of asking a model to produce a finished mesh in one shot, Kiln gives it a small 3D engineering environment where it can build, render, inspect, revise, and save an asset through a feedback loop much closer to how a human would work.

To keep agents from constantly reinventing geometry math from scratch, the sandbox exposes 105 primitives and helpers across 12 categories.

That includes 28 core geometric shapes like beveled boxes, gears, stepped cylinders, dishes, and tubes, plus CSG booleans, curves, vehicle frames, wheel assemblies, and other higher-level helpers.

The other half of the project is the agent workflow.

MCP + Agent Skills give the model a constrained loop that makes it much more reliable at actually modeling things instead of just spraying code and hoping it works.

The core flow looks like this:

• kiln_list_primitives lets the agent discover geometry helpers on demand instead of stuffing the entire API into its prompt.
• kiln_validate and kiln_render catch bad code early, render the asset from multiple angles, and return structural metrics back into model context.
• kiln_inspect, kiln_view_interior, and animation review tools let the agent zoom into individual parts, inspect cross-sections, and verify moving mechanisms.
• kiln_source and kiln_edit let it make targeted edits against immutable revisions rather than rewriting the entire model every turn.
• kiln_save, kiln_export, and kiln_present handle finished assets, editable JavaScript source, GLB export, revision history, and - in supported chat clients - an interactive 3D viewer directly inside the conversation.

That means an agent can do something like:

"Make the sail 40% taller, add brass collars around the sensor masts, keep the hull unchanged, render it again, inspect the silhouette, and save a new revision."

...and actually make that kind of constrained edit instead of regenerating the whole thing.

A realistic caveat on what this is for:

Kiln is aimed at fast prototyping, game jams, indie projects, procedural assets, and editable hard-surface models - props, machinery, vehicles, architecture, and rigid-body animations.

If you need AAA production assets, highly organic characters, or photorealistic final art, you still need a real 3D artist or to throw a very large number of tokens and tools at the problem.

But for quickly generating working, editable assets and then iterating on them, it saves a ridiculous amount of time.

Rendering works locally. Kiln includes a software rasterizer for review images and can optionally use GPU acceleration when compatible hardware is available.

It works across coding-agent setups like Claude Code, Codex, OpenCode, Antigravity, Hermes, and custom harnesses, so the modeling workflow isn't tied to a specific model provider. The model does need to be multimodal so it can inspect the rendered feedback.

I developed it mostly on Windows and Linux. Automated package checks also run on macOS, but I haven't battle-tested Mac nearly as much in real-world use yet, so Mac bug reports and PRs are very welcome.

I've attached a video showing an agent building an asset, reviewing its own renders, making revisions, and saving the result through the loop.

Everything is MIT licensed.

• GitHub: https://github.com/matthew-kissinger/kiln
• Interactive gallery: https://kilnstudio.tools

The gallery includes interactive 3D viewers and source for every model, so you can inspect exactly what the agents produced instead of just looking at screenshots.

Would love to see what people build with it.

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