Read SDUK Studio's published articles and book a provisional discovery call.
Scored across 3 tools
The three tools have distinct purposes: booking a discovery call (write action), fetching a single blog post by slug, and listing blog posts. The two read tools (endpoint-public-post and endpoint-public-posts) are clearly distinguished by singular vs. plural and the explicit slug parameter, so misselection risk is low.
Names mix a verbose operation description (endpoint-book-discovery-call) with simple resource-based names (endpoint-public-post, endpoint-public-posts). The prefix 'endpoint-' is consistent, but the verb/noun structure is inconsistent across tools, making the set feel ad-hoc.
With only three tools, the server feels thin for a 'Studio Discovery' purpose. A discovery or content platform would typically need more operations (e.g., create/update blog content, manage leads), so this count is under-scoped.
The surface is severely incomplete: there is no tool to create or update blog posts, no lead management beyond booking a call, and no way to retrieve a lead or discovery call details. Core CRUD/lifecycle coverage for a discovery/content domain is missing, which will force agents into dead ends.
Run "Book a discovery call" (POST /discovery/book) — an action of this application. It runs immediately when you call it; there is no separate confirmation step, so only call it once you have gathered everything it needs from the user. Business rule: The discovery interview captures a lead as an anonymous visitor — the public role holds this endpoint but has no direct lead-create, so provisioning the lead row is the endpoint's whole purpose. The result tells you what happened — report that back honestly.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| company | No | ||
| country | No | ||
| summary | No | ||
| timeline | No | ||
| full-name | Yes | ||
| project-type | Yes | ||
| tenancy-need | No | ||
| data-residency | No | ||
| proposed-route | No | ||
| requested-time | No | ||
| compliance-level | No | ||
| data-volume-band | No | ||
| alternative-times | No | ||
| entity-count-band | No | ||
| concurrent-users-band | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the two most important traits: immediate, non-confirmed execution and a write side effect (provisioning a lead row) under the public role. It omits auth requirements, idempotency/duplicate-call behavior, and reversibility, which matter for a mutation endpoint.
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, front-loaded with the action, then the execution semantics, then the rationale. The parenthetical business-rule sentence is long and somewhat tangential, but it explains why the endpoint exists rather than padding.
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 16-parameter mutation tool with 0% schema coverage and no output schema, the description leaves critical gaps: no parameter guidance, no auth/permission context, and only a vague 'the result tells you what happened' instead of what the result contains.
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 0% across 16 parameters, and the description adds no field-level meaning at all beyond 'gather everything it needs.' It doesn't clarify the 3 required fields (email, full-name, project-type) or the enum vocabularies, so the agent must infer everything from bare property names.
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?
States a specific verb+resource and even the HTTP route ('Run "Book a discovery call" (POST /discovery/book)'), so the action is unambiguous. However, it offers no differentiation from the sibling endpoints (endpoint-public-post/posts), and those siblings are plausibly adjacent contact/lead flows, so an agent gets no help choosing between them.
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?
Explicitly states the precondition for calling: it executes immediately with no separate confirmation step, so gather everything needed from the user first. That is real when-to-use guidance, but it never names an alternative tool or a when-not-to-use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run "Public blog post by slug" — a read-only operation of this application (GET /public/posts/:slug). Reads: blog-post, blog-category. Call it when the user asks for what it provides; results are live and scoped to them.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose that this is a read-only GET operation and that results are 'live and scoped to them' (user-scoped data). It omits failure behavior (e.g. missing slug/404), auth requirements, and rate limits, so it goes beyond the bare minimum but not far.
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 operation is front-loaded, which is good, but the final clause ('Call it when the user asks for what it provides') is filler that takes space without adding meaning. The quoted title and parenthetical route are reasonable, but the sentence is not fully efficient.
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 one-parameter, no-output-schema, no-annotation read tool this covers the essentials: what it returns (blog-post, blog-category data) and that it is live/user-scoped. It lacks any note on what happens when the slug is absent or unknown, leaving a gap in an otherwise thin contract.
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?
There is one parameter at 0% schema description coverage; the schema gives only type and maxLength. The description's 'by slug' implies the slug identifies the post but adds no format, lookup, or error semantics beyond that, so it barely compensates for the coverage gap.
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 names a specific verb and resource (GET /public/posts/:slug, 'Public blog post by slug'), so an agent knows it fetches a single post rather than a collection. It stops short of explicitly contrasting itself with the sibling endpoint-public-posts, so differentiation is only implicit.
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?
"Call it when the user asks for what it provides" is circular and gives no actionable trigger; it never names the alternative (endpoint-public-posts) or a condition that selects one over the other. Only the implied 'by slug vs list' distinction carries any routing value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run "Public blog posts" — a read-only operation of this application (GET /public/posts). Reads: blog-post, blog-category. Call it when the user asks for what it provides; results are live and scoped to them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose that this is read-only and that results are live and scoped to the user. That is meaningful context beyond the schema, but it omits auth requirements, pagination, and result shape, so the behavioral picture remains partial.
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?
It is a single sentence, but part of it is wasted: 'Run "Public blog posts"' echoes the tool name, and 'Call it when the user asks for what it provides' adds no information. The useful facts (GET route, read-only, entities read) are buried alongside this filler.
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 zero-parameter, read-only tool with no output schema, the description need not explain return values, and the route plus read-only note cover the essentials. Still, the absence of any real routing guidance against its two siblings leaves a gap for an agent choosing between them.
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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly does not invent parameters or filters that do not exist.
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 names a specific resource ('Public blog posts'), the HTTP route (GET /public/posts), and the entities it reads (blog-post, blog-category), which is more than a tautology. However, 'Run "Public blog posts"' largely restates the tool name, and it never distinguishes this list endpoint from the singular sibling endpoint-public-post, leaving the agent to infer the plural/singular split.
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 only guidance is 'Call it when the user asks for what it provides,' which is circular and provides no real selection criteria. There is no mention of when NOT to use it or how it relates to endpoint-public-post or endpoint-book-discovery-call, so routing between siblings is left entirely to inference.
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.
endpoint-book-discovery-callendpoint-public-postendpoint-public-postsOfficial AI agent for Stuart Innovations. Real-time project scoping, tech-stack advisory, and UK-based development capacity for Web, Mobile, and AI solutions
Rafe Blandford's published career, case studies and writing. Read-only; no route to contact him.
An interactive portfolio built for AI conversations. Browse work, services, and book calls.
Explore Raze services, pricing, projects, availability, and confirmed introduction bookings.
