(everything I write about MCP means "remote MCP" by the way. Local MCP is completely pointless)
MCP provides you a clear abstracted structure around which you can impose arbitrary policy. "identity X is allowed access to MCP tool Y with reference to resource pool Z". It doesn't matter if the upstream MCP service provides that granularity or not, it's architecturally straightforward to do that mapping and control all your MCP transactions with policies you can reason about meaningfully.
CLI provides ... none of that. Yes, of course you can start building control frameworks around that and build whatever bespoke structures you want. But by the time you have done that you have re-invented exactly the same data and control structures that MCP gives you.
"Identity X can access tool Y with reference to resource pool Z". That literally is what MCP is structured to do - it's an API abstraction layer.
This argument always sounds like two crowds shouting past each other.
Are you a solo developer, are you fully in control of your environment, are you focused on productivity and extremely tight feedback loops, do you have a high tolerance for risk: you should probably use CLIs. MCPs will just irritate you.
Are you trying to work together with multiple people at organizational scale and alignment is a problem; are you working in a range of environments which need controls and management, do you have a more defensive risk tolerance ... then by the time you wrap CLIs into a form that are suitable you will have reinvented a version of the MCP protocol. You might as well just use MCP in the first place.
Aside - yes, MCP in its current iteration is fairly greedy in its context usage, but that's very obviously going to be fixed with various progressive-disclosure approaches as the spec develops.
KPT is a language app specifically targeted at explainable verb conjugation for highly inflected/agglutinative languages. Currently works for Finnish, Ukrainian, Welsh, Turkish and Tamil.
These are really hard languages to learn for most speakers of European languages, particularly English - we're not used to complex verb conjugations, they're hard to memorise and the rules often feel quite arbitrary. Every other conjugation practice app just tells you right/wrong with no explanation, which doesn't really help you learn when there are literally hundreds of rules to get right.
The interesting part was using an LLM to create a complete machine-executable set of conjugation rules, which are optimized for human explainability, and an engine to diagnose which rule is at fault when you get it wrong. There's several hundred rules needed for each language in order to cover all exceptions.
NB as a bonus it also works fully offline because my best practice hours are when I'm travelling and have poor connectivity.
Really cool stuff, I thought about launching something similar earlier this year, there's definitely a market there. I see a lot of AI-ative startups coming up against compliance requirements way earlier than before, with much smaller teams, and most existing solutions just need too much from you as you engage.
How do you see yourself against someone like delve.co?
Seems weird to cripple the product by not allowing me to (optionally) disable the internal antenna and instead use and tune an external antenna. And I suspect that is likely to make a difference when you are on the edge of coverage, but you know exactly where the relevant cell tower is, a few km away.
How does the Teltonika work out for you - I nearly bought it earlier this year but it doesn't have support for external antennae. I'm just on the edge of 5G coverage and I'm not sure I want to splash out on something which I can't tune for decent reception.
Seems an odd omission for a ruggedised outside modem - the Unifi also seems to not support external antennae.
(I'd also prefer a unifi version just so it fits in the with rest of the networking infra I have in the mökki.)
On the plus side, maybe this means the endless churn of JS libraries will finally slow down and as someone who isn’t a JS developer but occasionally needs to dip their toe into the ecosystem, I can actually get stuff done without having to worry about 6-month old tutorials being wrong and getting caught in endless upgrade hell.
Only if you're only talking about income from work. If you own property in country A which you rent out while you live & work in country B, then you probably still owe tax on that rental income in country A. (but it will depend on the exact wording of the relevant DTA if one exists)
And since you are now filling in two tax returns for different countries, with different tax allowances across rental income and work income which interact in decidedly non-linear fashion, you probably need to make sure both country A and B have no confusion about where your work income was earned.
Having spent the last 8 years obsessively counting days across the UK and Finland (and every other country I have visited) exactly to account for this scenario, I am very sympathetic to attempts to solve this problem space!
Physical goods you can hold until tariffs are paid.
Services are paid for by invoices between two corporate entities whose legal domicile may have nothing to do with the real country of origin of the services.
Lots of European SaaS providers invoice US customers from their US subsidiary - impossible to distinguish the transaction in order to put a tariff on it.
MCP provides you a clear abstracted structure around which you can impose arbitrary policy. "identity X is allowed access to MCP tool Y with reference to resource pool Z". It doesn't matter if the upstream MCP service provides that granularity or not, it's architecturally straightforward to do that mapping and control all your MCP transactions with policies you can reason about meaningfully.
CLI provides ... none of that. Yes, of course you can start building control frameworks around that and build whatever bespoke structures you want. But by the time you have done that you have re-invented exactly the same data and control structures that MCP gives you.
"Identity X can access tool Y with reference to resource pool Z". That literally is what MCP is structured to do - it's an API abstraction layer.