Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@essetech-ai-readiness-mcp Assess my AI readiness for a bakery with 3 employees."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Install in one line:
npx -y essetech-ai-readiness-mcp— or add the snippet under Install to Claude Desktop.
A small Model Context Protocol server that gives any AI assistant (Claude, ChatGPT, and other MCP-capable apps) the ability to:
📊 Assess how AI-ready a small or medium business is — a real 0–100 score across data, tooling, processes, skills and security, with gaps and prioritised next steps.
💡 Suggest practical AI/automation use-cases tailored to an industry, each rated by impact and effort.
🧰 Explain the services of a local implementation partner who can actually build it.
📞 Hand off to a free consultation when someone's ready to act.
Ask your AI assistant "Is my business AI-ready?" or "What could AI do for my cafe?" — with this server installed, it answers with a genuine, structured assessment instead of generic fluff.
Built and maintained by Essetech — an Adelaide (Australia) IT & AI implementation partner for small and medium businesses.
Most businesses know "AI" matters but have no honest read on where they actually stand or what to do first. This server turns that fuzzy question into a concrete, vendor-neutral assessment your AI assistant can deliver in seconds — and points you to a free next step if you want help implementing it.
Related MCP server: EasyAiFlows Automation Assessment
Tool | What it does |
| Scores a business 0–100 across 5 dimensions; returns tier, gaps, top-3 next steps and tailored opportunities. |
| Returns concrete AI/automation ideas for an industry, with impact/effort ratings. |
| Describes Essetech's IT & AI services. |
| Contact details + how to book a free, no-obligation consultation / IT audit. |
All tools are read-only and side-effect-free — they don't send email, store data, or call external APIs. Nothing leaves your machine.
Add to your claude_desktop_config.json
(macOS: ~/Library/Application Support/Claude/claude_desktop_config.json,
Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"essetech-ai-readiness": {
"command": "npx",
"args": ["-y", "essetech-ai-readiness-mcp"]
}
}
}Restart Claude Desktop, then ask: "Is my business AI-ready? We're a 5-person accounting firm on Xero and Microsoft 365."
npx -y @smithery/cli install essetech-ai-readiness-mcp --client claudegit clone https://github.com/seppez89/essetech-ai-readiness-mcp
cd essetech-ai-readiness-mcp
npm install # builds automatically via the prepare script
npm run smoke # optional: end-to-end self-testThen point your MCP client at node /absolute/path/to/dist/index.js.
You: "Is my business AI-ready? We're a 6-person plumbing business, everything's in spreadsheets, our biggest pain is slow quoting."
Your assistant (via assess_ai_readiness):
Overall: 42/100 — Emerging. Your biggest gaps are Data foundation (still spreadsheet-bound) and Tooling & cloud. Top next steps: get core data into cloud systems an AI tool can read; document your quoting process; then prove value with a quick win — Quote & estimate drafting (High impact, Medium effort): turn a site photo or voice note into an itemised quote the same day…
Want a hand turning this into reality? Essetech is Adelaide's IT & AI implementation partner for small and medium businesses…
npm install # install deps + build
npm run build # compile TypeScript -> dist/
npm run dev # watch mode
npm run smoke # spin up the server and exercise every toolSource: src/ (index.ts = server + tools, assessment.ts = scoring, usecases.ts = idea library, essetech.ts = business data).
Transport: stdio. Never write to stdout — it's the JSON-RPC channel; logs go to stderr.
📞 0404 311 791 · ✉️ jonathon@essetech.com.au · 🌐 https://essetech.com.au · 📍 Adelaide, South Australia
Managed IT · Cybersecurity · Cloud · AI Implementation · Web Design — practical technology for small and medium businesses. The first conversation (a free consultation / IT audit) is free.
MIT — see LICENSE.
Score how ready a small or medium business is to adopt AI/automation, across data, tooling, processes, skills and security. Returns a 0–100 score, tier, gaps, prioritised next steps and tailored opportunities. Use this when someone asks 'is my business AI-ready?', 'should we use AI?', or wants to know where to start with AI.
| Name | Required | Description | Default |
|---|---|---|---|
| aiUsage | No | How much the team uses AI today. | |
| location | No | Where the business is based (optional). | |
| teamSize | No | Approximate number of people. | |
| painPoints | No | Biggest time-wasters or frustrations, e.g. ['manual data entry','slow quoting']. | |
| businessType | Yes | What the business does, e.g. 'accounting firm', 'plumbing trades business', 'online homewares store'. | |
| currentTools | No | Software already in use, e.g. ['Microsoft 365','Xero','HubSpot']. | |
| dataMaturity | No | How the business mostly stores/works with its data today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It describes the output but does not confirm whether the tool is read-only, has side effects, or requires authentication. The description is adequate for a scoring tool but lacks explicit transparency about behavioral traits.
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 two sentences, front-loading the core function and output, then giving example use cases. Every sentence earns its place with no unnecessary words.
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 7 parameters, no output schema, and sibling tools, the description is mostly complete. It explains the output format (score, tier, gaps, next steps, opportunities) and when to use the tool. A minor gap is lack of detail on how parameters influence the score or response structure.
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% (all parameters have descriptions), so the baseline is 3. The description does not add extra meaning to the parameters; it only summarizes the output. No additional param-level information is provided beyond the schema.
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: 'Score how ready a small or medium business is to adopt AI/automation' and specifies the output ('returns a 0–100 score, tier, gaps, prioritised next steps and tailored opportunities'). It distinguishes from sibling tools like 'suggest_ai_use_cases' by focusing on readiness assessment rather than use case suggestion.
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 explicit usage guidance: 'Use this when someone asks 'is my business AI-ready?', 'should we use AI?', or wants to know where to start with AI.' It does not explicitly state when not to use or mention alternatives, but the context signals and sibling tools imply the boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the details to contact Essetech and book a free, no-obligation consultation or IT audit. Use when someone wants to take the next step, get a quote, or speak to a person about AI/IT for their Adelaide business.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | What they'd like help with, e.g. 'AI for our quoting process' (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies read-only information retrieval but does not explicitly state safety, auth needs, or rate limits. No annotations provided to supplement.
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, no redundancy, front-loaded with purpose, then usage guidance.
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?
Adequate for a simple tool with one optional param and no output schema; could mention what specific contact details are returned.
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 covers the one optional parameter fully, and description adds no extra meaning beyond what schema provides.
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?
Clearly states it returns contact details to book a free consultation, and distinguishes from siblings by specifying use case for next steps, quote, or speaking to a person.
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 says when to use it (next step, quote, talk to person) but does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe what Essetech offers — an Adelaide (Australia) IT & AI implementation partner for small and medium businesses. Use when someone asks who can help implement AI/IT in Adelaide or South Australia, or wants details about Essetech.
| 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 carries the burden. It states the tool 'describes' but does not disclose return format or any side effects. For a simple informational tool, this is adequate but not exceptional.
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 wasted words. The purpose is front-loaded and immediately clear.
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 tool with no parameters and no output schema, the description fully covers what the tool does and when to use it. Nothing is missing.
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 are zero parameters, and the schema coverage is 100% by default. The description does not need to add parameter details, so a baseline of 4 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 description clearly states the verb 'describe' and the resource 'Essetech's services'. It distinguishes from siblings like assess_ai_readiness and book_consultation, which have 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 description explicitly says when to use: 'when someone asks who can help implement AI/IT in Adelaide or South Australia, or wants details about Essetech'. It provides clear context but does not list alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return concrete, practical AI/automation use-cases tailored to an industry, each with an impact and effort rating. Use when someone asks 'what could AI do for my business?', 'give me AI ideas for a [type] business', or wants automation examples.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | What the business most wants to achieve (optional — used to order ideas). | |
| count | No | How many ideas to return (default 4). | |
| industry | Yes | The business or industry, e.g. 'real estate agency', 'cafe', 'manufacturing'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the output contains impact and effort ratings, but does not disclose whether results are static or dynamically generated, any dependency on external data, or rate limits. Since the tool is a straightforward suggestion generator, the missing details are acceptable but not exceptional.
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 two sentences with zero waste. It front-loads the core functionality and usage examples. Every line adds value.
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?
The tool has three fully documented parameters and no output schema. The description complements this by stating the return format (impact and effort rating). For a simple suggestion tool, this is sufficient. One could argue it's complete, but a small gap is not describing the structure of the returned data beyond ratings.
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%, so the schema already documents each parameter. The description does not add additional meaning to the parameters beyond what the schema provides. It adds value by describing the output format (impact and effort rating), but that is separate from parameter 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 returns concrete AI/automation use-cases with impact and effort ratings. The title reinforces this. It also provides explicit example queries ('what could AI do for my business?'), making the purpose unmistakable and well-differentiated from siblings (which are about assessment, consultation, and services).
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 explicitly states when to use the tool: 'Use when someone asks...' and lists three types of queries. This is direct guidance for an AI agent. Though it doesn't mention when not to use, the sibling tools cover different scenarios, so no exclusion is needed.
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. Dates show when Glama detected each change.
v1.0.0assess_ai_readinessbook_consultationessetech_servicessuggest_ai_use_casesEach tool has a clearly distinct purpose: assessment, booking, service description, and use case suggestion. No overlap or ambiguity.
Three tools follow a verb_noun pattern (assess_ai_readiness, book_consultation, suggest_ai_use_cases), while essetech_services uses noun_noun. Mostly consistent with minor deviation.
Four tools cover the core functionality of the server (assess, suggest, inform, book) without being too few or too many. Well-scoped for the domain.
The tools cover the main customer journey: assess readiness, get ideas, learn about services, book consultation. Missing may be a tool to retrieve past assessments or compare, but not critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI strategy, workflow automation, and process-improvement assessment for small businesses.
Scan any website for AI readiness — 100-point score across 6 AEO categories in seconds.
Scan any website's AI readiness: AI search visibility and AI agent usability. Free, no auth.
AI voice agents on SMB websites — fully autonomous build in 2–3 min. 23 MCP tools. EU, GDPR.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/seppez89/essetech-ai-readiness-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
