axeldunkel

I do agree here and would even go further: if a text is good I do not care whether it came from a human or AI. What I don't like: bad texts are harder to detect (especially when AI generated)

Lets assume this real - for humans these condensed tools make sense. For an agent I'd argue it takes him more tokens to understand these condensed infos since he most probably knows the right tools anyways and does not need the shortcuts.

so cronic combined with a healthcheck, immediate failure alerting and integration for e.g. graylog or fluentd - would be a killer :-)

What I've done for years: "generate" email addresses on the fly like zz-<portal>@mydomain.com and have a catchall rule for zz* in my main inbox. So if I get any mail or spam I can see where it originates from (and by doing this it I was able to point a portal to the fact that obviously they leaked mail addresses). By doing this I can block a single mail address.

This does break though when you are required to SEND with this email address.

Good question on Code Mode internals.

In Code Mode the model sees only two tools by default: list_tools(pattern) and execute_code(code). list_tools takes a regex and returns TypeScript signatures for matching tools. execute_code runs JavaScript that calls them.

So when the model actually needs the GitHub API for example, it calls list_tools("github.*pull") - it gets back just the typed signatures for those endpoints, and then writes code against them. Your second hypothesis is the mechanism: a meta-tool that queries on demand. The typed signatures (first hypothesis) are what the model reasons over once it has them.

That is what really brings the cost down. A large API as MCP tool definitions is easily 40-50k tokens upfront. The same API via list_tools + execute_code is ~1k for the two tool descriptions, plus only the signatures the model pulls per query.

A bit more on DADL, since this is what people typically ask first - why ANOTHER standard?

DADL is on purpose narrower than e.g. OpenAPI. It describes only the tool surface that an agent is allowed to call - not the full API contract that humans, SDK generators, gateways, docs and mocks need. In practice this means fewer parts to think about: method, path, parameters, access class, descriptions, and policy metadata. The point is to make the allowed actions explicit and small enough to actually review.

Every MCP project I have seen wraps APIs imperatively - custom code per backend. DADL is the only declarative format I know of that makes the allowed surface reviewable in a PR diff. That is a deliberate trade-off: less flexibility, more auditability.

Why YAML? Because humans really read and edit it. I wanted something small enough to review in a PR, diff cleanly, easy for LLMs to generate AND to write by hand when needed. In practice this is more important than maximum expressiveness.

What DADL can do: describe HTTP tools with typed parameters, declare auth requirements, attach policy metadata and caller constraints, provide a compact tool surface to the model - and attach a simple 'access' badge to each tool that flags it as read-only or dangerous. And errors come back in a form the LLM can reason about, not as crashes that break the flow.

What DADL is not trying to do: replace OpenAPI, capture every edge case of complex APIs, or be a full SDK generation format.

A few questions I get often:

Does this work for every API? No. APIs with very stateful flows, weird auth handshakes, streaming edge cases or messy responses still need custom handling. Some APIs map cleanly to DADL, some do not - but for those that do not, you can still plug in an existing MCP server through ToolMesh, and Code Mode applies to it too.

Why not generate from OpenAPI? OpenAPI is a great source material. You point an LLM to the DADL specification, to the OpenAPI definition - and you get a valid DADL that usually only needs optimisation.

So far there are 20 DADLs in the public registry covering 1,833 tools (GitHub, Cloudflare, GitLab, DeepL, Hetzner Cloud and more). If there is a specific API you would want to see as DADL, just ask - I am happy to add it.

If you want to try before cloning: https://demo.toolmesh.io is a public instance with the HN APIs loaded (login dadl/toolmesh). Works with Claude.ai, Claude Desktop, Claude Code, and ChatGPT - setup takes 30 seconds: https://toolmesh.io/demo

You are also right and I half agree - but the same issue arises with new employees. They already have some of this experience you are talking about - but usually there is something about the very environment they are in which causes them to learn lessons the hard way. And that experience does not transfer easily to the next colleague - and even less to an LLM. The only way I see to solve this is by having an "organisational memory".

Well the LLM might well have read all operating procedures etc. - just like the teenager - but it has not *experienced* issues himself/herself/itself. If you look at the published statements about "AI deleted my..." those AI models clearly knew what went wrong AFTER they caused it...

Amazing, looks too good to be true :-) But no ToS, Imprint, whether it is commercial or open source?

I only use a decay function to see how "hot" a chunk is - not for forgetting old ones. What concerns me more are memory chunks with errors in them - they need to be corrected/removed by some other mechanism, not by decay (since they might get retrieved often).

Think of AI just like of a genius 16-year old. Accidents will happen - only let AI and the 16-year old access systems where you are sure you have a recovery plan.

the better the tokenizer maps text to its internal representation, the better the understanding of the model what you are saying - or coding! But 4.7 is much more verbose in my experience, and this probably drives cost/limits a lot.

why does this matter?

Great site! I once created muelltonne.de (german for "trashcan") where users could send (spam) mails which they did not like - and got poems or jokes in return that were made from exactly the same letters (plus some remains that could not be used). Reading tweets nowadays cries out for a new enhanced version...

Great idea, I do like the concept to give the LLM more information and context so it can decide what approach is better. But why do you implement it as a mcp server and not as a proxy to have the full context?

Sounds like "security by obscurity" to me - if you think AI is so good at finding security issues - it will find them in compiled code as well. Why not using it in your favor and let it search for bugs you'd otherwise not find?

I like the approach to bring in the context surgeon as a wrapper that sees the conversation and can attach ids to the lines. You might even use the surgeon to replace parts with summaries?

Nice clean project - Python 3.14 as a requirement might be an issue for adoption...

I'd bet this does work but how do you solve the problem with scoring the quality of a modified agent?

I still have a 486 linux system from those days - has not been turned on in this century but I'll try some day together with a glas of whisky :-)

Interesting that you manually mapped GET→resources and POST→tools. We hit the same pattern with ToolMesh.io so often that we built a declarative format for it — DADL, a YAML file that describes the REST API mapping, and the gateway generates the MCP server at runtime. No code, no deployment per API. The boilerplate of wrapping every REST API into an MCP server is probably the biggest adoption blocker right now.

The connection lifecycle is one problem, but even with ephemeral connections you still have the authorization gap — MCP has no built-in concept of per-tool, per-user permissions. We ran into this building an MCP aggregator (ToolMesh, Apache 2.0) where 15+ backends connect through a single gateway. Our approach: OpenFGA for fine-grained ReBAC authorization on every tool call, plus an Output Gate that can run e.g. DLP policies before results reach the LLM. The attack surface isn't just about which servers are connected — it's about what each agent is allowed to do with them. https://toolmesh.io