I threw something into the first round, so I can give you a rough read on how it went. Mine was nowhere near polished. It was a working hack, ugly code, a rough video of it doing its job, and about a page explaining what problem it solves and what I'd do with actual funding. That was enought to get through review and onto the community vote, and I'd say the writeup mattered more than the polish. What they seemed to care about was whether you clearly understood the problem and whether the thing actually runs, not whether it looks like a finished product.
So on your specific worry: a half-working script plus sketches is not a one-shot burn if you frame it right. Show the script doing even part of the job, be upfront about what works and what doesn't, and lay out a short plan for the rest. What would sink you is a slick document about an idea with nothing runnable behind it. Judges and voters both want to see proof of life. And honestly, don't sit on it for months polishing. Somebody else out there is annoyed by the same material-swap pain and might be building the same fix right now. On categories, small utilities and scripts absolutely fit. A good chunk of the winners from round one were workflow tools and add-ons rather than big firmware rewrites, so don't talk yourself out of it because yours is little. If your tool makes the toolchanger workflow less annoying, that's exactly the sort of thing they said they want. For what counts as a submission, the fund page on their site is the authority and it's clearer than the blog posts. My memory is you describe the project, link to wherever the work lives, and include some evidence it exists. Double check that list yourself though, because I'm going off what I did a while back and they may have tweaked the template for round two. One practical tip: record your demo video early, even with the half-working version. It forces you to explain the thing plainly, and that explanation is basicly your writeup done.