Services, case studies, 169 data and AI guides, and AI readiness scoring. Read-only, keyless.
Scored across 6 tools
Each tool targets a clearly distinct resource or action: readiness questions vs. scoring, case studies, contact details, services, and resource search. The two readiness tools are complementary and explicitly linked by their descriptions, so there is no realistic misselection risk.
All tool names are snake_case and follow a predictable verb_noun pattern: get_*, list_services, search_resources, score_ai_readiness. The single action verb 'score' is still consistent with the domain and clearly named.
Six tools is well-scoped for a read-only consultancy information and readiness-assessment server. Each tool has a clear role, and there are no redundant or filler tools.
The surface covers the server's apparent domain: services, case studies, contact details, searchable guides, and the full readiness-assessment flow from questions to scoring. Since it is explicitly read-only and URLs are returned for deeper content, no critical lifecycle gaps are evident.
The 16-question AI readiness assessment (four areas: strategy, people, data, change; 15 questions scored). Ask the user each question, then call score_ai_readiness with the answers.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional: return just one section's questions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds genuinely useful context beyond those annotations: that the tool is meant for interactive use with the user, the four assessment areas, and that only 15 of the 16 questions are scored.
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?
Two sentences with no filler: the first states what the tool returns and the assessment structure, the second gives the required next action. The content is front-loaded and every word serves a purpose.
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 read-only tool with one optional parameter and no output schema, the description plus schema is sufficient. It explains the assessment composition, the intended user interaction, and the follow-up call. It doesn't specify the shape of the returned questions, but the instruction to ask the user each question makes the purpose clear.
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 schema fully documents the optional 'section' parameter with enum values and a description, so schema coverage is high. The description enriches the enum values by mapping them to the four assessment areas and referencing the question count, but it does not introduce meaning the schema lacks. Baseline 3 is appropriate because the description adds only modest context.
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 identifies the tool as returning a 16-question AI readiness assessment organized into four named areas. It also distinguishes the tool from the sibling score_ai_readiness by explaining the intended relationship. The minor 16-vs-15 scored question discrepancy is the only slight ambiguity.
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 an explicit workflow: ask the user each question, then call score_ai_readiness with the answers. This tells the agent exactly when and how to use the tool, and names the sibling that should be invoked next. It effectively prevents confusion with the scoring tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The three published case studies with real, verifiable outcomes: Smarter Services (1.5 days of admin freed weekly), 1NCE (multilingual AI support assistant), Slimstock (AI chat on their own content).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional: return just this case study; one of "smarter-services", "1nce", "slimstock" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that the tool is read-only, idempotent, and non-destructive. The description adds useful content scope (three specific case studies with verifiable outcomes), but does not reveal additional behavioral details such as response shape or slug-omission behavior. It does not contradict the annotations.
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?
A single, front-loaded sentence that efficiently names the resource and enumerates the available case studies in parentheses. There is no filler or redundant repetition of schema information.
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?
This is a simple read-only tool with no required parameters, so the annotations and schema cover most of the contract. The description names all available items and their focus areas, though it does not explicitly describe the response structure or confirm behavior when no slug is 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?
The input schema has full description coverage for the single optional 'slug' parameter, listing the three valid values. The description adds no new parameter semantics, so the baseline score of 3 is appropriate.
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 tool name 'get_case_studies' combined with the description clearly identifies the resource: the three published case studies. The description lists each case study and its outcome, distinguishing this tool from siblings like list_services and get_contact_info.
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 no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of sibling tools. The intended usage is only implied by the tool name and the case-study content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to contact the Shipshape Data team on a user's behalf (email; a person replies, usually within one working day). This server has no write tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations: contact is via email, a human replies, and replies usually arrive within one working day. It also reinforces the read-only nature by stating the server has no write tools. This is consistent with the readOnlyHint, idempotentHint, and destructiveHint annotations.
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 compact and front-loaded with the core purpose, followed by a concise behavioral note. Both sentences add meaningful information: the first explains what the tool does, and the second sets server-level read-only expectations. There is no redundancy or 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, no-output-schema tool, the description is complete. It covers how to contact the team, what kind of response to expect, and the server-level constraint that no write tools exist. An agent has enough information to decide when and how to use this tool.
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 semantics burden on the description. The empty schema is fully self-explanatory, and the description appropriately focuses on the tool's behavior rather than inputs.
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 purpose: contacting the Shipshape Data team on a user's behalf via email. It also adds the expected response behavior (a person replies, usually within one working day), which makes the tool's role unambiguous and distinguishes it from the content-oriented sibling tools.
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 clear context for when this tool is appropriate: when an agent needs to contact the team on a user's behalf. It also notes that the server has no write tools, which helps set expectations. It does not explicitly name alternatives or exclusion criteria, but no sibling tool is a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 13 services of Shipshape Data (a London AI consultancy): AI strategy, data consultancy, AI development, data migration, and nine specialisms including MCP connections and RAG. Returns names, descriptions, and page URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional: return just this service, e.g. "ai-strategy" or "mcp-connections" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful non-obvious details: the exact service count, the inclusion of MCP connections and RAG, and that the result includes names, descriptions, and page URLs. This meaningfully exceeds annotation-only context.
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?
Two concise sentences with no filler. The action, scope, examples, and return content are all front-loaded and every phrase earns its place.
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, read-only list tool with one optional parameter and strong annotations, the description is sufficiently complete. It names the return fields and the optional filter behavior. The absence of an explicit output shape is a minor gap, but acceptable given no output schema exists.
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 slug parameter is fully documented in the input schema with an example, so the description carries little parameter burden. The list of service categories provides hints about valid values, but the schema already supplies the core semantics.
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 lists Shipshape Data's 13 services, identifies the verb and resource precisely, and even previews service categories and return fields. It does not explicitly differentiate from sibling tools like search_resources, so it stops short of a 5.
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 implies this is the canonical way to list the company's services but provides no explicit when-to-use guidance or alternatives among siblings. An agent can infer usage from the catalog framing, but it is not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score AI readiness answers with the same maths as shipshapedata.com/ai-readiness: returns a 0-100 score, one of five maturity bands with guidance, per-area averages, and the weakest area with advice.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Either 16 option indices (0-4, all questions in order) or 15 point values (1-5, scored questions only, in order) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, and destructiveHint false. The description adds behavioral value beyond these by specifying the return contract: a 0-100 score, five maturity bands with guidance, per-area averages, and the weakest area with advice. This is additional transparency about what the call produces.
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?
A single front-loaded sentence that efficiently packs the action, the reference method, and the concrete output list without redundancy or 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?
With one parameter, no output schema, and minimal annotations, the description covers the core information an agent needs: inputs are answers, outputs include a score, bands, averages, and advice. It could optionally mention that the questionnaire comes from get_ai_readiness_questions, but that is inferrable and not essential 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 description coverage is 100%: the parameter answers is fully documented with the two accepted formats (16 option indices or 15 point values) and their ordering. The description adds no further parameter detail, so the baseline 3 applies.
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 action (Score AI readiness answers), cites the reference method, and enumerates concrete outputs. This clearly differentiates it from sibling tools like get_ai_readiness_questions, which is the questionnaire counterpart, and search_resources/list_services, which serve different purposes.
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 wording 'Score AI readiness answers' implies the context of scoring questionnaire responses, but the description does not explicitly state when to use this tool versus alternatives such as get_ai_readiness_questions, nor mention that questions must first be obtained. The usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Shipshape Data's library of 201 practical guides on data and AI. Each result includes the questions the guide answers and its URL (every page also serves a markdown twin at URL + index.md).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 5 | |
| query | Yes | Search terms, e.g. "data lineage" or "RAG architecture" | |
| category | No | Optional category filter; one of the names from resource categories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower, and the description still adds real value by describing the result shape (questions each guide answers plus URL) and the markdown-twin convention at URL + index.md. It does not disclose ranking behavior, whether the match is keyword or semantic, or what an empty result looks like.
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?
Two sentences, front-loaded with the identification of the corpus, then the result shape. Every clause carries information the agent can act on and nothing is redundant.
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?
With no output schema, the description correctly picks up the burden of describing return values, including the markdown-twin detail. For a three-parameter, fully documented search tool this is close to complete; only match semantics and result-count behavior are unstated.
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 is 100%, so query, limit, and category are all documented in the schema; that sets the baseline at 3. The description adds no parameter guidance of its own — nothing on how query terms combine, what the default limit means in practice, or where category values come from.
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 (Search) and a precisely scoped resource (Shipshape Data's library of 201 practical guides on data and AI), which is distinguishable from siblings like list_services and get_case_studies. It stops short of explicitly naming those alternatives, so an agent must infer that this is the content-lookup path rather than the structured-data path.
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?
Usage is only implied: an agent can infer this is the tool for finding guides on a topic, but there is no explicit 'use this when…' or exclusion versus siblings such as get_ai_readiness_questions. No mention of when a category filter is preferable to a query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find governed AI capabilities and verify signed receipts. Read-only, no account.
Free, read-only data on about 4,900 AI companies, open AI jobs and dated AI news, with source links.
Read-only AI project discovery, verification, comparison, shortlisting, and stack planning.
Read-only AI impact metrics with search, methodology and cited sources. No authentication required.
Add one secure layer between your agents and this server.