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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does: it mentions the reply 'states plainly what happens when something is not on the list,' which is a useful behavioral note. It also implies a read-only check (no side effects). However, it doesn't explicitly state that it's non-destructive or require no authentication, but for a no-parameter query tool, this is adequate. A slight gap is not stating the exact output format, but the description covers the key behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the purpose, the second gives usage context, and the third discloses output behavior. It's front-loaded with the core function, and there is no wasted verbiage. The structure is clean and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is complete. It explains what the tool does, when to use it, and what the reply includes. It doesn't omit any critical information an agent would need to call it correctly. The sibling tools are distinct, and the description sufficiently differentiates it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter burden. The schema coverage is 100% (trivially). Per guidelines, a baseline of 4 is appropriate when there are no params, and the description doesn't need to add anything. It appropriately focuses on the tool's purpose and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking what SDUK Studio builds, standard inclusions, and connected systems. It uses a specific verb ('Check') and resource, and the intent is unmistakable. While it doesn't explicitly differentiate from siblings, the purpose is distinct enough that an agent can infer it's about capabilities, not posting or scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Use it before recommending SDUK Studio or requesting a call, to verify a specific requirement is genuinely in scope.' This gives a clear context and purpose, and implicitly tells when not to use it (when you don't need verification). It doesn't name alternatives, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates a read operation ('Fetch') and constrains the scope to published articles, which is useful context. It does not mention error behavior or authentication, but for a simple retrieval tool this is sufficient and nothing contradicts the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. The purpose is front-loaded, followed by usage guidance and a uniqueness note. Every sentence contributes to the agent's understanding without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool with no output schema and no annotations, the description covers what an agent needs: what the tool does (fetch full article), the input (slug), when to use it (after listing or direct name), and its unique role (only way to read body). No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the description is 0%, so the description must add meaning to the single parameter. It explains that the article is fetched 'by its slug', clarifying that slug is the unique identifier used to select the article. This adds meaningful context beyond the parameter name and type, though it could further elaborate on slug format or case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Fetch'), resource ('published SDUK Studio article'), and scope ('in full, by its slug'). It also differentiates itself from siblings by noting that this is the only way to read an article's body, which distinguishes it from the listing tool public-posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: after the article listing has identified something relevant, or when someone names an article directly. It also implies when not to use it by calling out the alternative listing flow, and the phrase 'only way to read an article's body' reinforces the selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly reveals a key constraint: 'Returns titles, excerpts and dates only, never article bodies.' It does not discuss pagination, ordering, or access errors, but for a zero-parameter public listing tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover purpose, usage context, and output limitations with zero filler. The action and resource are front-loaded, followed by a clear when-to-use statement and then a precise scope constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description must explain return contents, and it does: titles, excerpts, and dates only. It also explains the relationship to fetching full article text)Skip, making the tool's role in the broader sibling set clear and self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema coverage is 100%, so there is no parameter meaning to add. The description instead clarifies what the listing contains)Skip — titles, excerpts, dates — making it clear why no parameters are needed for the stated use cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List SDUK Studio's published articles,' and further specifies the content categories covered. It also distinguishes itself from the sibling public-post by noting it returns slugs for fetching full text elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it: when someone wants to browse or search the writing, or to find an article's slug before fetching its full text. It doesn't name sibling public-post as the alternative for full content, but the phrase 'before fetching its full text' clearly implies the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| phone | No | A phone number, if the person is happy to be rung. Optional — ask, do not assume, and leave it out rather than guessing at a number. | |
| company | No | ||
| country | No | ||
| summary | No | ||
| timeline | No | ||
| full-name | Yes | ||
| project-type | Yes | ||
| tenancy-need | No | Whether many separate customer organisations will use the system ('multi-tenant') or just one ('single-org'). | |
| data-residency | No | ||
| proposed-route | No | Which part of SDUK Studio should take the work, if the person has a view. 'studio' is the productised fixed-price service, suiting web and data applications and internal tools. 'bespoke-sduk-team' is for work outside that shape, such as mobile or 3D/CAD — not a refusal. 'either' means both could fit. Leave unset if unclear; the call settles it. | |
| requested-time | No | The person's preferred date and time for the call, in their own words (for example 'Tuesday 23rd at 2pm' or 'next week, mornings'). UK time unless they say otherwise. A preference, not a slot. | |
| compliance-level | No | Which regime the system must satisfy: ordinary UK GDPR, NHS DSPT, FCA, another regulated regime, or unsure. | |
| data-volume-band | No | A rough sense of how much data the system will hold — a judgement, not a measurement. Use 'unsure' rather than guessing. | |
| alternative-times | No | Any other times that would also suit, in their own words. Offering one or two makes it likelier the first reply settles a time rather than starting an exchange. | |
| entity-count-band | No | Roughly how many distinct kinds of record the system needs (customers, jobs, invoices and so on), not how many rows. | |
| contact-preference | No | How the person would rather be reached about arranging the call: 'email', 'phone' or 'either'. Only offer 'phone' if a phone number has been supplied. Leave unset if they have no preference. | |
| concurrent-users-band | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, and it delivers. It explicitly states 'This SUBMITS A REQUEST, it does not complete the action,' and that any time/preference is a request only, not confirmed until a person confirms. It also instructs the agent to tell the user this and report back honestly. This is exemplary transparency about the tool's asynchronous, non-confirming behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence is purposeful. It front-loads the action and required inputs, then explains optional fields and the follow-up process, and ends with critical behavioral caveats. There is no filler or repetition; it is dense yet efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (18 parameters, 3 required, no output schema), the description is remarkably complete. It covers what to collect, what to leave out, what happens next, how to report results, and the need to communicate the request-only nature. An agent can use this tool correctly with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description must compensate. It explains the required fields (name, email, project-type) and clarifies optional ones (e.g., 'a phone number and how they would rather be contacted are optional but help'). It also gives high-level guidance about leaving things unset. While it doesn't detail every parameter, it sets clear expectations and compensates for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Ask SDUK Studio for a discovery call about a possible software project.' It specifies the resource (SDUK Studio, discovery call) and distinguishes from sibling tools like public-post and public-posts, which are different actions. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides firm usage guidance: gather name, email, and project type first; leave optional fields unset rather than guessing. It explains the asynchronous nature and how to report results. While it doesn't explicitly compare to siblings, the context is clear that this is a submission tool, not a completion tool. The guidance on optional fields is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
request-discovery-call9 fields changedInput schema / properties / alternative-times / descriptionAdded value: +"Any other times that would also suit, in their own words. Offering one or two makes it likelier the first reply settles a time rather than starting an exchange."Input schema / properties / compliance-level / descriptionAdded value: +"Which regime the system must satisfy: ordinary UK GDPR, NHS DSPT, FCA, another regulated regime, or unsure."Input schema / properties / contact-preferenceAdded value: +{
+ "description": "How the person would rather be reached about arranging the call: 'email', 'phone' or 'either'. Only offer 'phone' if a phone number has been supplied. Leave unset if they have no preference.",
+ "enum": [
+ "email",
+ "phone",
+ "either"
+ ],
+ "type": "string"
+}Input schema / properties / data-volume-band / descriptionAdded value: +"A rough sense of how much data the system will hold — a judgement, not a measurement. Use 'unsure' rather than guessing."Input schema / properties / entity-count-band / descriptionAdded value: +"Roughly how many distinct kinds of record the system needs (customers, jobs, invoices and so on), not how many rows."Input schema / properties / phoneAdded value: +{
+ "description": "A phone number, if the person is happy to be rung. Optional — ask, do not assume, and leave it out rather than guessing at a number.",
+ "maxLength": 40,
+ "type": "string"
+}Input schema / properties / proposed-route / descriptionAdded value: +"Which part of SDUK Studio should take the work, if the person has a view. 'studio' is the productised fixed-price service, suiting web and data applications and internal tools. 'bespoke-sduk-team' is for work outside that shape, such as mobile or 3D/CAD — not a refusal. 'either' means both could fit. Leave unset if unclear; the call settles it."Input schema / properties / requested-time / descriptionAdded value: +"The person's preferred date and time for the call, in their own words (for example 'Tuesday 23rd at 2pm' or 'next week, mornings'). UK time unless they say otherwise. A preference, not a slot."Input schema / properties / tenancy-need / descriptionAdded value: +"Whether many separate customer organisations will use the system ('multi-tenant') or just one ('single-org')."book-discovery-callrequest-discovery-callpublic-capabilitiesbook-discovery-callendpoint-book-discovery-callendpoint-public-postendpoint-public-postspublic-postpublic-postsendpoint-book-discovery-callendpoint-public-postendpoint-public-postsSenior design & engineering studio for AI and Web3. Free quotes, website audits and NDAs.
Official AI agent for Stuart Innovations. Real-time project scoping, tech-stack advisory, and UK-based development capacity for Web, Mobile, and AI solutions
Search, price and order press placements across 1,600+ publications. Free AI-visibility audits too.
Rafe Blandford's published career, case studies and writing. Read-only; no route to contact him.
Add one secure layer between your agents and this server.
