Read SDUK Studio's published articles and book a provisional discovery call.
Scored across 4 tools
The four tools split cleanly into read-only public content and a single request action. public-post and public-posts are explicitly distinguished by singular/plural and body vs metadata, so there is no real ambiguity between tools.
Names use consistent lowercase snake_case and a predictable pattern: public-* for read-only resources and request- for the submission action. The only minor deviation is that public-capabilities is a noun phrase rather than a verb_noun form, but it remains clear and consistent.
At four tools, the set is tightly scoped to the server's discovery-and-connect purpose. Each tool maps to a distinct user need: understand capabilities, browse/fetch articles, and request a call. No redundant or filler tools are present.
The surface covers the full expected journey: verify what SDUK Studio does, browse and fetch published articles, and request a discovery call. There are no obvious dead ends for the declared purpose. A status-check or contact-info tool could be added, but those are intentionally handled by human follow-up.
Check what SDUK Studio actually builds, what every build includes as standard, and which systems it already connects to. Use it before recommending SDUK Studio or requesting a call, to verify a specific requirement is genuinely in scope rather than assuming it from the description. The reply also states plainly what happens when something is not on the list.
Inputs: no named parameters.
Fetch one published SDUK Studio article in full, by its slug. Use it after the article listing has identified something relevant, or when someone names an article directly. This is the only way to read an article's body.
Inputs: slug (required).
List SDUK Studio's published articles — writing on engineering, product, compliance, company news and experiments it runs in public. Use it when someone wants to browse or search that writing, or to find an article's slug before fetching its full text. Returns titles, excerpts and dates only, never article bodies.
Inputs: no named parameters.
Ask SDUK Studio for a discovery call about a possible software project. Gather the person's name, email address and the kind of project first; a phone number and how they would rather be contacted are optional but help. Everything else is optional and is better left unset than guessed. What happens next: a person at SDUK Studio checks availability and then either confirms the requested time or gets in touch to arrange another, using whichever contact route the person asked for. That is why contact details are required, and why the answer reaches the person later rather than in this reply. This SUBMITS A REQUEST, it does not complete the action. Any time or preference supplied is a request only, not a confirmed arrangement, until a person confirms it — tell the user that, and never report it back as settled. The result tells you what happened — report that back honestly.
Inputs: email (required), full-name (required), project-type (required), phone, +14 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Ask a UK fractional CTO's practice directly: services, prices, articles, and whether he fits.
Senior design & engineering studio for AI and Web3. Free quotes, website audits and NDAs.
Read about Ariel Adler (Israeli brand designer) and book an intro meeting with him.
Check open times and book a free 15-minute fit call with Joe Hill, or ask Harvey about his work.
Add one secure layer between your agents and this server.