Services, case studies, 169 data and AI guides, and AI readiness scoring. Read-only, keyless.
Average 4.1/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: retrieving assessment questions, scoring assessment answers, listing services, retrieving case studies, searching resources, and providing contact info. The only related pair—get_ai_readiness_questions and score_ai_readiness—are complementary rather than overlapping, with one delivering the questions and the other processing the answers.
All tool names follow a consistent snake_case verb_noun pattern: get, list, score, and search. The naming style is uniform and predictable, making it easy for an agent to infer behavior from the tool name alone.
Six tools is a well-scoped size for a company information and readiness-assessment server. Each tool contributes a distinct function with no redundancy, and the count is comfortably within the ideal range.
The tool surface covers the server's apparent purpose comprehensively: services, case studies, resources, contact information, and a complete AI readiness assessment flow. The explicit note that the server has no write tools appropriately sets expectations, and users can obtain URLs/markdown for deeper content.
get_ai_readiness_questionsAThe 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.
get_case_studiesAThe 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.
get_contact_infoAHow 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_servicesAList 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_readinessAScore 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_resourcesASearch Shipshape Data's library of 169 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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: each result includes the questions the guide answers and its URL, plus the note that a markdown twin exists at URL + index.md. This helps the agent understand the return format and available content.
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 sentence front-loads the verb and resource; the second sentence provides valuable output details in compact form. Every sentence 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?
This is a simple read-only search tool. The schema documents all parameters, annotations cover safety and idempotency, and the description explains what results contain. Nothing essential for correct invocation is missing. The markdown-twin note is a nice extra that improves usability.
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%, with query, limit, and category all documented in the input schema. The description adds no additional parameter-level meaning. It sits at the baseline expected when the schema carries the full weight of parameter documentation.
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 uses a specific verb ('Search') and clearly identifies the resource: 'Shipshape Data's library of 169 practical guides on data and AI.' This distinguishes it from sibling tools like get_case_studies or list_services, making the tool's scope 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 implies when to use the tool: when searching for practical guides on data and AI. However, it does not explicitly state when not to use it or mention alternatives, even though sibling tools like get_case_studies and list_services represent different resource types. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Find governed AI capabilities and verify signed receipts. Read-only, no account.
Read-only AI project discovery, verification, comparison, shortlisting, and stack planning.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Read-only website analytics, AI referrals, crawlers, goals, revenue, and funnels.
