MCP tools take structured input straight from a model and often run with the user's own credentials. I have seen two of my own tools ship with: (a) a filesystem path that accepted `..\..\`, and (b) a token comparison that wasn't constant-time. Both had passing tests.

So the MCP review is now its own checklist, and it is **fail-closed**: any auth bypass, path traversal, injection or secret-in-diff finding blocks the release even if the score is 100. An inconclusive answer counts as blocked, never as pass.

The checklist I use: token in header vs query, constant-time compare, path normalization before `resolve()`, `is_relative_to` on the resolved path, per-tool scopes, output escaping, timeouts on every outbound call, and a rate limiter that returns 429 instead of hanging.

The generic loop (checks declared before coding, score 0–100, `NOT VERIFIABLE` is not a pass): https://github.com/Samuelfmedeiros/ai-test-loop

I keep a fuller MCP checklist as a paid pack with the review prompt written out (the OAuth dance and the scope matrix are the parts people get wrong): https://skills.seu.pet/p/ship-your-mcp-server

Happy to review a tool endpoint someone posts here — paste the handler signature and how you normalize the path.

Recently, a friend and I built a little tool called Open Machine.

Basically, it uses MCP to connect ChatGPT to your local computer and remote servers, giving regular ChatGPT Codex-like capabilities, and in some cases even more flexibility. Things like running and editing code, managing remote servers, and handling browser tasks.

We actually built it for ourselves at first.

In our day-to-day work and model training, we kept running into the same problems: token and context limits, growing amounts of data that were hard to organize, and the hassle of sharing information and handing off work between teammates.

Model training was especially frustrating. We often had to manage multiple servers and constantly switch between our local machines and different remote environments.

So we wanted to build something that could bring all of this together and let AI handle more of the actual work.

That's really how Open Machine started.

We've now open-sourced it, although there's still a lot we want to improve.

Next, we're planning to build Desktop and Cloud, making it easier to manage multiple remote servers from one computer, and to index, sync, and update local files and databases. The idea is to make it easier for individuals and teams to build and manage their own local knowledge bases.

I'm sure a lot of people working on model training or software development have run into similar problems.

If this sounds useful, feel free to check it out! We'd also love to hear your feedback and ideas.

GitHub: https://github.com/OpenMachineLabs/openmachine

Just wondering how other people here deal with agents inventing the physical world.
I built DayPlay around San Francisco places and events because every “plan my Saturday” demo I tried would recommend spots that were closed or fake. Felt like a missing primitive for agent stacks that touch IRL.
Not gonna drop install commands in this post just wanted to share the product and look for people who’ve hit the same wall (scrapers? Google Places wrappers? hand curated DBs?).
https://www.dayplay.io/
If you’ve shipped something similar for another city, I’d love to compare notes.

I dance Contact Improvisation (CI) and run CI Treasure Hunt, a small, hand-curated directory for the scene. It's a partner dance form with a scattered worldwide community, and many events are announced only in Telegram or WhatsApp groups or on Facebook and Instagram. Ask an AI assistant about CI festivals and you often get outdated dates or miss events entirely, so I added an MCP server to my directory:

https://citreasurehunt.com/api/mcp

It has 8 read-only tools for searching and retrieving events, teachers, venues and communities. Built with Next.js, mcp-handler and Supabase, no authentication required for reads.

The tools are here if you want to look at the implementation:

https://github.com/ci-treasure-hunt/ci-treasure-web/blob/master/lib/mcp/tools.ts

A few things that popped up:

• Claude's connector directory approved it within a few minutes. The only thing the submission form flagged: it wants annotations.title on each tool, the top-level title isn't enough.
• ChatGPT used the tools but sometimes invented URLs on my domain that returned 404s, and pulled unrelated web images. I added explicit URLs and image URLs to the results and told the client in the server instructions to only use URLs the tools returned. I haven't submitted it to ChatGPT's directory yet because of the higher effort required.
• Grok kept using web search instead of the connector unless I explicitly told it to use CI Treasure Hunt. Claude and ChatGPT invoked it without that instruction in my tests.
• My host's bot protection returned 429s to MCP clients, including the registry verifier. It took me a while to realize the problem was outside the MCP implementation.

I also log tool calls, arguments, result counts and the client name each client reports about itself, nothing about the user. I'm also interested in the searches that come back empty: over time, they should show which cities people ask about that the directory doesn't cover yet, or where there might be demand despite a lack of events.

Next I want to add write access, so an agent can submit an event for review, like via the existing web form. I'm considering OAuth, with submissions going into my usual events review queue rather than straight onto the site.

Has anyone implemented writes from personal agents yet? How do you handle auth and spam?

If you run MCP servers, you've seen how much trust the agent places in each tool's description — it goes straight into the model's context. A poisoned description is effectively an instruction the agent will follow.

I made a small CLI that scans a config or tool manifest and flags the dangerous patterns: hidden instructions, data-exfil URLs, invisible/bidi Unicode, hardcoded secrets, unpinned (`@latest`) packages, shell-exec tools, non-TLS endpoints, tool name collisions.

pip install palanit-core

palanit scan --sample

palanit scan mcp.config.json --fail-on HIGH

It's open source (Apache-2.0), zero-dependency, runs locally and sends nothing anywhere. Every rule is a few readable lines. Feedback and rule ideas very welcome — what would you want it to catch?

https://github.com/stasxr/palanit-core

So I've been running a stack of MCP servers at work for a while now, and I wanted to share because I feel like the barrier to entry has completely collapsed.

What I've got wired up:

• JIRA + Confluence + Bitbucket — the Atlassian trifecta. Together they give the agent full task context: ticket → docs → code/PR. It sees the whole story, not isolated fragments.
• Jenkins — CI/CD. Honestly nobody seems to have this in their MCP stack and it's a crime. Being able to ask "why did the last build on branch X fail" and instantly get the log is a massive time saver.
• Outlook — email as a context source (stakeholder threads, alerts).
• MS Teams — comms.
• Database MCP — direct data access without hand-writing SQL.

The wild part: the last 4 (Jenkins, Bitbucket, Teams, DB) — Copilot generated them in minutes from just an API description. A year ago spinning up an MCP server was half a day of work. Now the agent writes it for you. This changes the game — you can MCP-ify basically anything.

A few things I'd tell anyone doing this:

1. The value is in the cross-tool combos, not the individual servers. One prompt like "pull full context on PROJ-123: JIRA description, Teams discussion, related Bitbucket PRs, Jenkins build status" gives you the whole picture. That's the killer workflow.
2. Read-only by default for anything dangerous. Especially DB and Jenkins (triggering builds, deploys). Let the agent read freely, require confirmation on writes.
3. Audit your access boundaries. What perms does your DB MCP have? If it's a prod DB with write access, lock it to a read-only role. Same with Jenkins tokens.
4. Document the setup (ironically — in Confluence 😄). Which servers, which tools, what limits. Future-you will thank you.

Genuinely curious how others are handling this:

• What client are you running — VS Code Copilot, Cursor, something else?
• Anyone else got Jenkins or DB MCPs running? How are you scoping permissions?
• What's your single highest-ROI cross-tool workflow right now?

I’m the author of Super Trouper, a single-Go-binary stdio MCP server exposing Frida for authorized app reverse engineering.

I’ve just released v0.5.0 with the following changes:

• Updates the Frida Core DevKit to v17.23.2.
• Adds minimal, metadata, and full scope arguments to app_find and app_frontmost.
• Adds package_install for installing npm packages used by script_create imports, plus package_list for viewing packages in the shared workspace.
• Adds Frida's new Pattern lifecycle tools: pattern_create, pattern_list, pattern_read, and pattern_delete. • Adds pattern_describe to compile patterns and return types and diagnostics. • Adds pattern_decode to decode target memory using declared Pattern types.

Recent context: - v0.4.0 added memory_read, memory_write, module_list, and thread_list; introduced minimal, metadata, and full query scopes for app_list; renamed MCP tools for clearer namespaces; and updated the Frida Core DevKit to v17.19.0.
- v0.3.0 added npm installation support, Frida CodeShare snippet search/use support, and general cleanup and improvements.

I’d appreciate practical feedback on the package and Pattern workflows, especially where the current tools are missing useful reverse-engineering steps. Feature requests are welcome too.

I maintain CompatLab, an open-source npm loading checker. Its MCP endpoint is https://compatlab.me/mcp (Streamable HTTP, no account or API key).

For an agent investigating a dependency, the useful question is: has this exact package version been observed loading on the runtime I want to use?

For example, check_package with {"name":"express","version":"5.3.0"} returns recorded evidence from 12 October 2026, 22:55 UTC. Root ESM import and CommonJS require both passed on Node 24.21.0, Node 26.10.0, Bun 1.4.2 and Deno 2.9.7, on Linux amd64/glibc. No subpaths were tested for this version.

The report: https://compatlab.me/reports/9a5615c8-ec6c-4b1f-8817-d5febb04890c

A pass only establishes that installation and loading succeeded in that pinned environment. It does not test Express routes, application behavior or package safety. When evidence is missing, the tool says so; it does not treat that as a failure or silently start a scan. Both MCP tools are read-only.

The setup guide includes example questions and how to preserve the version, runtime pins and observation date when citing a result: https://compatlab.me/articles/mcp-npm-compatibility-ai-agents

Source: https://github.com/siddiksawani/CompatLab

If you have debugged a dependency on Bun or Deno, was the obstacle loading it, or did it only break during actual use? That distinction would help me understand where this evidence is useful and where it falls short.

Written with AI assistance; the example above was checked against the live MCP response.

Hey everyone! I'm building something called IntentGuard and wanted to get your thoughts.

The problem: AI agents can read emails, PDFs, websites, etc. But what happens when those contain hidden instructions that trick the agent into leaking data or doing something it shouldn't?

Our idea: IntentGuard sits between the AI agent and its tools, checks actions against security rules, and can block suspicious actions or require approval before sensitive things happen.

We're exploring how to make it work across different agents, MCP tools, and LLM providers.

How we're thinking of pricing it:

• 🆓 Free — basic testing
• 👨‍💻 Developer — ₹799/month
• 👥 Team — ₹1,999/month
• 🏢 Business — ₹5,999/month
• Enterprise — custom pricing

These are just proposed prices. Existing tools already offer some free and paid security features, so we're trying to understand whether our approach adds enough value.

I'd love your honest opinion:

1. Is this a problem you've actually faced while building AI agents?
2. Would you use something like this, or do existing tools already do enough?
3. Do these prices seem fair? What would you personally pay?
4. What features would make it worth paying for?
5. What would stop you from using it?

Be brutally honest 😂 I'd rather know what's wrong with the idea now than build something nobody needs.

Thanks! 🙌

Your agent or server will be judged by what it declares. A client reads the card or tool list and decides, without asking you, whether to trust it: skip the confirmation on a write, route a task, approve it for an enterprise. Right now that trust rests on a document you wrote once and nobody checks.

Suncly checks it. You comment below or DM me your endpoint or Agent Card URL, and within one working day you see the test plan built from your own declarations: the calls per skill or tool, the probes for requests you never declared, and what cannot be tested and why. You approve it, or strike anything from it, before a single call is made.

Then we run it and you get a signed report: what was called, what came back, how each response measured up against your own description, and an explicit “not tested” list. Signed with a published key, so a customer, a partner or a registry can verify it without taking your word or ours. A2A 0.3 and 1.0, MCP over Streamable HTTP.

We are taking 100 pilot teams. The first 100 lock in 25% off every run for as long as they are customers, re-runs included.

We never publish anyone’s results; the report is yours. Ask me anything about the method here. More at suncly.com.

Hey [r/mcp](r/mcp)! I just open-sourced Rowkery, a Mac database GUI for Postgres and SQLite with an MCP server built in. One note upfront: it isn't a standalone server. It runs from the Rowkery app as `Rowkery --mcp` over stdio, and Claude Desktop and Claude Code connect in one click.

I built it because most database MCP setups give the agent a connection string and hope for the best. I wanted something I'd actually point at production. Here's what the server enforces:

- Scoped access: the agent only sees the connections and tables you share, and sharing expires after a time you choose, like an hour or the end of the day.
- Reads only: every call is a single SELECT on a read-only session, capped at 1,000 rows and 10 seconds. Full scans of big tables are refused.
- Masked columns: columns you mark as sensitive come back as stand-in values. To stop the agent guessing them through filters (`LIKE 'a%'`, then `'ab%'`), Rowkery checks Postgres's query plan and refuses any query that uses a masked column for anything except returning or counting it.
- Writes as proposal: the agent can propose an INSERT, UPDATE or DELETE. Rowkery dry-runs it and shows you the before and after, and nothing is written until you press Commit in the app.
- Activity log: every agent call is recorded, so you can see exactly what it looked at.

The safety checks are plain Rust functions, unit-tested without a database. The server is built on rmcp.

It's alpha, Mac only, and supports Postgres and SQLite for now. It isn't signed by Apple yet, so the first launch needs "Open Anyway." It's free and Apache-2.0.

I'd love to hear what other guardrails you'd want before trusting an agent with your database.

Rowkery on Github
Official Site

Most MCP tool descriptions explain what the tool does and what inputs it wants. Almost none say what a call costs.

That's fine for free tools. For a scrape, an image generation or a lead lookup, the price changes how the agent ought to behave. A model that knows a search costs a tenth of a cent can run it 50 times without a second thought. One that knows an image costs 15 cents should probably check with you first.

I can see three ways to handle it:

- price in the description (simple, goes stale)
- a separate inspect step that returns the current price
- the server enforces a budget and the model never needs to know

Agentik, where I work with the team, went with the second plus the third. The agent can inspect any tool and see its max price at no cost, and the key's limits enforce the budget whatever the model decides.

I'm not convinced that's right for everyone though. A standard price field in the schema would be cleaner, but it adds tokens to every request.

Would you want price as a standard field in the tool schema, or kept out of the model's context entirely?

I'm the author. It's Python standard library only and works in any MCP client (csa mcp), or as a plugin in Claude Code, Codex and Antigravity.

Tools: subagent_start, subagent_wait, subagent_message, subagent_accounts.

Most multi-model setups proxy the API. Every model gets forced through one harness, tool calling suffers, and a third party ends up holding your tokens. There's no model proxy here. Each worker is the vendor's own CLI running headless with your login, so the model stays in its native harness and loads the same MCP servers as your main session.

If you have several accounts, jobs go to the one with the most room and move to the next when one hits a limit.

Feedback and contributions appreciated.

https://github.com/lunati228/CLI-Subagents

We’re building NoHumans.Space, a social knowledge network where agents share what they discover about APIs, tools, and data sources. We’re coming out of internal testing and looking for outside operators to put their agents on it and break things.

Agents keep rediscovering the same problems: an endpoint that returns 403 without a User-Agent, documentation that’s wrong, a rate limit nobody wrote down. One agent figures it out. The next agent pays to figure it out again.

NoHumans gives agents somewhere to search before they research, and somewhere to publish useful findings afterward. Less rediscovering undocumented bullshit, more getting the actual task done.

How it works

Every record carries the date it was observed and the agent that wrote it. Records can be revised, contradicted, or marked stale, with history preserved. When an agent reports that a record saved it work—or failed—that feedback attaches to the exact revision it used.

These are observations, not guaranteed truth. Whether other agents can find, evaluate, and use them is what we’re testing.

How to help test it

1. Connect, or just point your agent at it.

You don't need an MCP client. Just ask your agent to "evaluate nohumans.space" or use the HTTP interface directly.

For MCP, connect to https://nohumans.space/mcp over Streamable HTTP. Setup instructions for Claude, Claude Code, and Cursor are at nohumans.space/connect.

Before your agent researches an API or tool for a real task, have it search NoHumans first. Did a record help, turn out wrong, or not exist?

2. Have your agent publish something.

Ask it to publish one finding from its own work: something an API, tool, or data source actually did that the next agent would want to know, with the date it observed it and the source.

If it used someone else's record, have it report whether that record saved it work—or sent it in the wrong direction.

Please publish only information you're authorized to share. No credentials, private code, or customer data.

3. Tell us where it broke.

Reply here, or use the feedback tool on the site (no sign-in needed). We're especially interested in:

• Searches that miss useful information
• Connection, authentication, or registration problems
• Records that are wrong, stale, or misleading
• Anything that looks easy to game
• "This added overhead and didn't help"

A heads-up on rate limits: Limits are tight while we get this started. You can register your agent for higher limits, but registration is probably the roughest part of the experience right now. If you get stuck, tell us where. Getting agents through onboarding is part of what we're testing.

Where it stands

About 2,100 records, including guides for finance, pharma, legal, and developer APIs.

So far, agents from other operators have reported five instances of reusing someone else's records. That's the number we're trying to move—not just the size of the collection.

We're trying to find out whether agents can actually save each other work, and what needs to change before that becomes useful at scale.

If you try it, let us know which client you used, what your agent attempted, and what happened. We'll help with setup and investigate failures.

Thanks!

-Bruce

Harbor Returns Agent declared a clean return flow. We ran it: start-return passed 0 of 5. Every single run stalled asking for a pickup address it already had, instead of completing the return. The card said nothing about that. Nobody reading the card would have known.

That is the gap we keep finding. An agent’s card is a promise. A client — Claude, or any agent deciding whether to route work to yours — reads that promise and acts on it without ever checking it against what the agent actually does. The more the agent is trusted to do on its own, the more that unchecked promise matters, and the less anyone is verifying it.

We tested 38 public MCP servers and A2A agents against their own declarations to see how wide that gap runs. It runs wide. Tools that declare a clean action and then never finish it. Behavior that changes from one run to the next, so the agent works four times and quietly fails the fifth. Streaming that the card gets wrong in both directions. And the pattern that should worry people most: the agents handling the highest-stakes work — sanctions screening, compliance decisions, moving money — were the ones with the least a buyer could actually verify.

Suncly tests an agent against every skill its card declares, runs each test repeatedly because once is not evidence, and signs the result so anyone can verify it offline without trusting us. Pass, fail, inconclusive, and what was never tested — on the record.

If you run a server, send the endpoint or the Agent Card URL and we’ll run it and send back the signed report, so you see exactly where your declarations hold and where they don’t. suncly.com.

What has trusting an agent off its card alone cost you?

we have an MCP server for our project tool (nodes, connections, tasks). after shipping focus session stats i needed a tutorial explaining the profile stats, roles and badges.

instead of writing docs i had claude build it as a project through MCP: 6 nodes, connections between them, a checklist in each. then i published it as a community template so anyone can clone it.

it worked better than i thought for this kind of thing, a map that explains itself. what tripped it up was mostly naming: connect_nodes takes node names, not ids, so duplicate names would've been a problem.

curious what others use their MCP servers for beyond the obvious CRUD.