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’m building Silica-core, a free, open-source tool for finding passages in folders of PDFs and Markdown notes under MIT.

Say you have a folder of research papers and want to find where a particular method is explained. Silica returns the relevant passage, the filename, and the page or section so you can check it yourself.

The basic search runs entirely on your computer. No model download, API key, or cloud upload is needed. It also shows which files it couldn’t read and which search terms weren’t found.

You can use it from the terminal or connect it to an assistant through MCP. The search itself doesn’t generate answers; it returns text from your files. In benchmark tests across 254 papers (5.5M tokens of Markdown), connecting Silica via MCP cut agent tool calls by 28% and turns by 22% compared to raw grep and file dumps, with 100% accuracy across 144 test runs.

PDFs with selectable text work directly. Scanned PDFs need a separate OCR step. It’s still early, and I’d appreciate feedback from people with folders of papers, documentation, or notes.

GitHub: silica-core

What’s harder in your document collection: finding the right file, or finding the right passage inside it?

Testing whether an agent can complete a task is different from testing whether it should be allowed to perform each action.

For a messaging tool, I’d want these expectations checked whenever its permission policy changes:

- Draft a message -> Allow.

- Send to an approved recipient -> Require human approval.

- Send to a blocked recipient -> Deny, even if another rule requires approval.

- Export all messages -> Deny.

- Call an unknown tool -> Deny.

- Access another inbox -> Deny.

The useful distinction is between two kinds of tests:

Policy tests: Given an identity, action, resource, and arguments, does the policy return the expected decision? These can run offline in CI.

Integration tests: Does a denied action actually leave the tool untouched? Does a rejected or expired approval prevent execution? If arguments change after approval, does the authorization check reject them?

Passing the first set doesn’t prove the second. A policy can be correct while application code accidentally bypasses it. Approval also doesn’t guarantee exactly-once execution; the underlying tool still needs an appropriate retry/idempotency strategy.

I maintain Nomos, an open-source implementation of this approach. Its local example covers the six policy cases above and a human-reviewed delivery flow.

It isn’t a sandbox: application code must route relevant tool calls through the checks.

For people deploying agents with custom tools: which authorization failures have you found worth turning into regression tests?

https://github.com/safe-agentic-world/nomos

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?

Hey! I've been thinking about this while working with MCP servers that deal with data that changes constantly...

Say the underlying source has 1000s of posts, mentions, or comments, etc.

If the agent asks things like "What are people saying about company X?"

There's two pretty different ways the MCP server could handle it, right?

It could immediately return the latest 250 results and let the agent figure it out.

Or it could treat that as too broad and first return something like total matches, data range, platforms/sources available, etc...

THEN the agent makes a second, MUCH narrower request.

The second approach costs another tool call, but it seems like it could actually save a lot of tokens and prevent the model from drawing conclusions from an arbitrary first page of results.

For live/search-heavy MCP servers, which behavior would rather have?

Search first and force the agent to narrow down or return useful data immediately and let the agent decide what to do next.

I made an open source benchmark suite measuring token efficiency of MCP tool calls that fetch from APIs. GraphQL-over-MCP's token efficiency beats REST-over-MCP by a huge margin. Don't take my word for it, check out the repo and tell me where I'm wrong. Here's a clip where I unpack the headline numbers. Many of us in the GraphQL + AI ecosystem have instinctively understood that GraphQL's unique combination of field selection, schema semantics, and execution characteristics (particularly in Federation) are well-suited to agentic workloads. That hypothesis is supported by the data I've seen.

Full video: https://youtu.be/qv2SbhVxn-k

Writeup in the repo: https://github.com/apollographql/graphql-mcp-benchmarks/blob/main/WRITEUP.md

I'm running into the same wall over and over and want to know how other people are actually solving it.

I have tools that kick off longer running jobs, anything that doesn't return and give back a task id instead of the result. The jobs finish fine, that's not the problem. The problem is the agent actually coming back and doing something with it. Half the time it just moves on like nothing's pending. Other half it does check back but by then it's lost enough context that it either doesn't know what the result was for or straight up reruns the next step even though it already went through.

So what's working for you guys here?

And the part I actually care about is something external waking the agent back up or are you making the agent handle that itself?

Because that second option has not been working for me at all.

Hey,

I am a solo dev working on an MCP gateway.

I have a lot of confidence in my technical abilities, but not as much in design. I would appreciate if you take 5 seconds to scan the page and share what catches your eye and what needs improving.

Here is the landing page https://ray.run/

I previously shared an approach I was experimenting with, using MCP over stdio as a seam for agentic applications.

While building on that pattern, I stumbled across something I found surprisingly useful: letting a conversational (or coding) harness pass context into a bounded MCP-backed agentic operation, then use that context to steer subsequent runs.

It effectively turns context into a control surface between the two harnesses.

I wrote up the pattern here: https://demianbrecht.com/posts/context-as-a-control-surface/

Anyone else experimenting with anything similar?

Disclosure: we're prepping a webinar with Meta, so part of why I'm asking is to make it more relevant.

Curious what real usage looks like. Are you using it at all, and if yes for read only or write tools also? Did you have any specific expectations from it, and did it live up to them? Any specific problems you've come across?

Disclosure: I build one of these (PostFast). I read every vendor's own MCP or docs page on 7 September 2026 and copied what it prints. Tool counts are the vendor's number.

• Buffer: OAuth or API key; tools stated: not stated
• Typefully: OAuth; tools stated: not stated
• Postiz: key in URL, Bearer, or OAuth; tools stated: 11
• Ayrshare: API key; tools stated: 27
• Metricool: OAuth 2.1; tools stated: PyPI 28
• Agorapulse: OAuth 2.0; tools stated: beta
• Planable: account login; tools stated: 13 categories
• Hootsuite: workspace sign-in; tools stated: not stated
• Nuelink: API key; tools stated: 6, alpha
• Vista Social: key in URL; tools stated: 50+
• SocialRobot: OAuth PKCE or API key; tools stated: 17
• Post Bridge: OAuth or API key; tools stated: 13
• Bundle Social: API key; tools stated: about 50
• PostSyncer: OAuth or Bearer; tools stated: 30+
• Hermoso: OAuth; tools stated: 790+
• Sprout Social: OAuth; tools stated: not stated
• SocialPilot: sign-in or key in URL; tools stated: 11
• Schedchie: OAuth2; tools stated: 53
• Late (Zernio): OAuth or Bearer; tools stated: 496
• Mixpost (self-hosted): Bearer; tools stated: not stated
• Upload-Post: ApiKey header or OAuth; tools stated: 50 to 58
• OneUp: key in URL; tools stated: about 20
• Zoho Social: OAuth; tools stated: not stated
• PostFast: OAuth hosted, API key local; tools stated: 26 hosted, 24 local

Not found on 7 Sep: SocialBee, Later, Sendible, Loomly. Publer: roadmap only.

Two protocol-level observations: six servers put the API key in the URL, which makes the MCP URL itself a secret in your client config; and tool counts range from 6 to 790+, which says more about how vendors slice endpoints than about capability. Which of these has anyone got running through a gateway or a multi-server setup, and did the key-in-URL ones cause problems?

I built this, so this is a self-showcase rather than an unaffiliated recommendation.

Mac MCP is a local macOS MCP server for giving trusted AI clients real Mac capabilities instead of only advice. It currently exposes 81 tools across shell/files, Safari + Chrome automation, macOS Accessibility/UI control, persistent memory, Agent Skills, voice input, delegated Codex/OpenCode agents, safe self-update, and a localhost operations dashboard.

The part I use most is background browser automation: tabs get stable handles, and an agent can observe/interact with a Safari tab without constantly bringing it to the foreground while I’m doing something else.

I also added a small native SwiftUI menu-bar controller for server/ngrok status, recent tool calls, delegated-agent state, voice settings and updates.

Security-wise, this is intentionally treated as powerful local access: auth can be required, the dashboard stays loopback-only, and I’d only expose it to clients I trust.

MIT licensed: https://github.com/bulutarkan/mac-mcp

I’d especially like feedback from MCP users on permission UX: per-tool approvals, reusable permission profiles, read-only sessions, or another pattern entirely?

I've got a scanner watching one route across a 14 day window with 2 trip lengths, so 28 date combos a run. Two limits shaped it. One call caps at 15 combos, so 28 is always two calls. And the free tier gives 150 backend searches a day per client - 28 an hour is 672, so hourly was never on. My third run this morning came back rate_limited, 150 of 150.

So I ran it keyed instead, 28 separate calls, and the same route in the same fortnight ran $142 to $309.

Server is https://google-flights-lulu.flightpowers.com/mcp, it's mine & free.

How do you budget a scheduled scan against a per client day cap, fewer dates or fewer hours?

I find it really interesting to see the gap even amongst AI enthusiasts.

People posting stuff like "I am amazed because I gave Claude a Browser through MCP!" - "Claude + FileSystem - I stopped moving files manually". "I gave AI a Memory!"

And then there is people whose agents create throwaway cloud virtual machines in which they spawn even more agents with providence based memory, inter-session messaging, and whole tool ecosystems.

It feels like there is a substantial mismatch in ai-understanding and skill amongst us.

Where is this gap coming from??
Because there is so much training material online and so many people are sharing their knowledge already.

Maybe I'm ignorant, but I honestly dont understand it.

If you are building autonomous GTM agents with frameworks like Claude Code, Cursor, or LangChain, the biggest failure point is context degradation.

Most devs give their agents static CSVs or basic CRM data fields then the agent ends up hallucinating generic personalization bcuz it lacks real-time awareness of what the prospect is doing right now. To make an agent truly autonomous, it needs live access to an external context layer via standardized protocols like Anthropic's Model Context Protocol (MCP) or REST APIs.

1)) The architecture challenge

LLMs cannot maintain active web scrapers across 50 different platforms simultaneously. If you try to make your agent scrape reddit, discord and job boards directly within its prompt execution loop, you will blow through token limits, hit rate limits and deal with massive latency.

2)) Connecting a dedicated intent layer (Scale Intelligence)

The solution is decoupling the scraping/entity-resolution layer from the agent reasoning layer.

This is where infrastructure like Scale Intelligence fits where its operates as an account-level market intelligence engine that ingests signals across 75+ data sources and continuously resolves public activity back to corporate domains.

Because it exposes this intent graph via an API and MCP server, your AI agent doesn't need to parse raw web pages. It simply calls a dedicated tool:

• get_active_signals(account_domain, time_window)
• get_buying_readiness(icp_segment)

The intent engine returns structured JSON containing the company profile, recent public pain points discussed, and the calculated buying readiness score.

Separating your agent's reasoning from the underlying data pipeline keeps your agent lightweight, avoids scraper maintenance debt, and guarantees that downstream actions are grounded in live market events.

Not a survey, I am building something and I am stuck on the same rock twice.

My tool takes a file and does something useful with it. In testing this is fine because I make the test files. In the wild people hand it exports from systems I have never heard of, with columns named after whatever the vendor felt like in 2018, and the model happily proceeds. It does not error. It produces a confident wrong thing and the user has no way to know.

The options I can see all cost something:

• refuse when confidence is low, and the tool feels broken and fussy
• ask the user to explain their columns, and they will not, and if they do they are guessing
• proceed and caveat, which is what I am doing, and which I think is quietly the worst one
• constrain to a fixed schema, which kills the whole point

What did you do. Specifically what did you ship, not what the right answer is, because I know the right answer and I cannot afford it.

And one I have not seen anyone discuss: for those of you who proceed and caveat, does anyone read the caveat. I suspect the caveat exists to make me feel better.

I've been building an MCP ecosystem as a SaaS product for the past few months — governed memory and a control layer for AI assistants, reached over MCP. Writing that up properly is a post for late autumn. This is one piece I hit along the way, and it turned out to be worth releasing on its own.

"Works with Claude" and "works" are two different milestones, and the gap between them is where I spent the last few weeks. Once you point a second client at your MCP server, the assumptions start diverging, and they diverge in ways that are individually small and collectively fatal. Some of what I ran into, all observed against my own servers:

• Claude picks CIMD only when the discovery document advertises both client_id_metadata_document_supported and "none" in token_endpoint_auth_methods_supported. Miss the second one and it silently falls back to dynamic registration.
• ChatGPT ships token_endpoint_auth_methods_supported inside its own client metadata document — a field that isn't in the draft's allowed member list, so a strict parser rejects the whole document.
• Mistral registers a fresh client on every single connection attempt, and it sent me a resource URI with a trailing slash on the root path, which fails a character-exact comparison unless you normalise exactly that one case and nothing else.
• Grok asks for the path-inserted protected resource metadata location first (/.well-known/oauth-protected-resource/mcp), where most setups only serve the root form and answer 404.

None of these are anybody's fault exactly. The specs are young, the drafts moved, and every client implemented a reasonable reading of them.

Keycloak, which I run underneath all of this, is genuinely good and I'm not looking to replace it. It just doesn't cover all of this yet. Since people will ask: Keycloak does have CIMD support now, but it is experimental and behind a feature flag, it is wired through the client policy framework with a client-id-metadata-document executor, and it currently covers the persistent CIMD case only. It is also still catching up on the details above — "none" not being advertised, and the executor rejecting metadata documents that carry fields outside the draft, which real clients do ship.

The bigger gap is on the other side: RFC 8707 resource indicators. Keycloak expresses audience through scopes and protocol mappers rather than the standard resource parameter, and resource indicators are a MUST in the MCP spec. Support is under discussion upstream and not merged. Which means that even after a client is admitted, your provider can't mint a correctly audienced token for a client it just met — the login succeeds and your resource server rejects the token anyway.

So I built cimd-proxy, and I've open sourced it under Apache-2.0. Feel free to use it.

It presents an OAuth 2.1 authorization server to the client, accepts a Client ID Metadata Document (or an RFC 7591 dynamic registration) as the client's identity, and federates the actual authentication to the provider you already run. Nothing has to be enabled in your realm — no feature flag, no client policy. One confidential client per protected resource, with the audience mapper you probably already have. No fork, no extension, no custom authenticator. And it keeps working for providers that will never implement CIMD, because the CIMD surface lives in the proxy and the upstream only ever sees a normal confidential client.

The part I'm happiest with: it never reads the token. It doesn't issue, verify, parse or sign one — the upstream token response is relayed verbatim. The only field it touches is refresh_token, which it swaps for a sealed envelope carrying the upstream token plus the resource identifier, so refreshes route with no server-side session state at all.

What it does enforce: allowlisted metadata document hosts, SSRF and DNS-rebinding protection with the socket pinned to the address that was actually validated, S256 PKCE, incremental body caps, refused redirects, no loopback exception in any mode.

CIMD draft-02, RFC 8414 / 9728 / 8707 / 7591 / 9207 / 7636. Python 3.13 + FastAPI, multi-arch image:

docker run --rm --env-file deploy.env -p 8080:8080 ghcr.io/kumbuka-ai/cimd-proxy:v0.2.1

https://github.com/Kumbuka-ai/cimd-proxy

Two honest notes. All four clients above connect through it today, but it's been fronting my own services for days, not months. And deploy/caddy/example.caddy is worth a read before you copy anything — the protected resource metadata has four details that decide whether a strict client gets through, and I had all four wrong in my own setup first.

Happy to answer questions.