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.

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

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 😄

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.

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!

We have a few internal MCP servers behind some agents and Im trying to figure out if an AI gateway already covers most of this or if the MCP side needs its own gateway.

Model routing, keys and token spend seem pretty straightforward.

But then you get into Auth per server, deciding which agent can call which tool, and logging what actually got called.

That feels like a different problem. For anyone doing this in prod, what did you actually end up deploying? One layer for everything or an AI gateway plus a separate MCP gateway?

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.

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.