Skip to main content
Glama

Enpitech

by io.github.enpitech
OverviewDiscussionsAdmin

Server Details

AgentReady website scans for AI agents, AI Hub search, newsletter and contact, from Enpitech.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored across 8 tools

Disambiguation4/5

Each tool has a distinct operation, and the view-opener vs raw-action pairs (contact_form/submit_contact, newsletter/subscribe_newsletter) are clearly separated. The only real ambiguity is agent_ready vs agentready_scan, which are close in name and purpose, though the descriptions explicitly distinguish the view experience from the raw data result.

Naming Consistency3/5

All names are snake_case, but they do not follow a consistent verb_noun pattern: newsletter and contact_form are nouns, submit_contact and subscribe_newsletter are verb-first, and agent_ready/agentready_scan are inconsistently split and ordered. The names remain readable and grouped by feature area, but the convention is mixed.

Tool Count4/5

Eight tools is a reasonable size for a business-site assistant covering scanning, lead capture, newsletter signup, and catalog search. The paired view/action tools add a little redundancy, but each one has a distinct role in the UI or API flow, so the count is not inflated.

Completeness4/5

The major workflows are covered: run an AgentReady scan as a view or raw data, email the report, search the AI Hub, contact Enpitech, and subscribe to the newsletter. There are no dead-end flows, though the catalog and CRM surfaces are intentionally shallow and not fully CRUD-complete.

Available Tools

8 tools
agent_readyCheck Agent ReadinessA
Read-only
Inspect

Opens Enpitech's AgentReady scanner as a view in the conversation. Inside the view the scanner fetches the site's public pages and runs 21 checks across five weighted categories (Discovery & Access, Readable for Agents, Structured Data, Actions & MCP, Trust & Safety), then shows a 0-100 agent-readiness score, the per-category breakdown, and the fixes ranked by the points each would recover. Use it when the user asks how ready a website is for AI agents, their own or any site they name: how readable, accessible or usable it is to AI, to agents or to AI crawlers; whether ChatGPT or Claude can read or use it; how to show up in AI answers; or for an audit of llms.txt, robots.txt, schema.org markup or MCP support. url is optional: with no URL the scanner opens with an empty input for the user to fill in. This tool returns only the URL it was opened with; the scan runs inside the view, via agentready_scan.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoThe site to scan, as the user gave it. A bare hostname like stripe.com is fine; the scanner normalizes it. Omit when the user has not named a site, and they will be asked for one.

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlYesThe site the scanner opened with, or an empty string when the user will type one in the view.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a read-only, non-destructive operation, and the description adds meaningful context beyond that: it returns only the URL, does not return scan results, and the scan executes asynchronously inside the view via agentready_scan. It does not discuss failure modes or permission-related behavior, but for a non-destructive view-opening tool this is solid transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat long, but every sentence earns its place: mechanics, usage triggers, optional parameter behavior, and return-value limitation. The trigger-phrase list is slightly redundant but still useful. It is front-loaded with the core behavior before moving to usage guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter, clear annotations, an output schema, and a named sibling for the actual scan, this description is complete. It explains what the tool does, what the user may ask, how the optional parameter behaves, and what the tool does not return. An agent has enough context to invoke it correctly and to route the user to agentready_scan for results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter and the schema already documents it fully, including that a bare hostname is fine and that the parameter should be omitted when no site is named. The description adds a minor behavioral detail about the empty input field, but the schema already conveys the essential omission behavior. Since schema coverage is 100%, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action and resource: it opens Enpitech's AgentReady scanner as a view)Skip with a scan capability. It also clearly distinguishes itself from the sibling agentready_scan by explaining that this tool only opens the view while the scan happens inside it. This level of specificity lets an agent know exactly what to expect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use it when the user asks how ready a website is for AI agents' and enumerates many concrete trigger phrasings. It also differentiates this tool from the sibling agentready_scan by noting the scan runs inside the view via that tool and that this tool returns only the opened URL. This is strong routing guidance with no reliance on inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agentready_scanGet AgentReady ResultsA
Read-only
Inspect

Runs the AgentReady scan on one site and returns the raw result, with no view. It fetches the site's public pages and runs 21 checks across five weighted categories (Discovery & Access, Readable for Agents, Structured Data, Actions & MCP, Trust & Safety), returning a 0-100 agent-readiness score, the per-category breakdown of every check, and the top fixes ranked by the points each would recover. When bot protection blocks too many checks the result carries limited: true and the headline score is not meaningful, though the per-check breakdown still is. When the scan does not run it returns ok: false with an errorType of invalid, unreachable, timeout or ratelimited. agent_ready runs this same scan and presents it as a visual report, so this tool fits the cases a view does not: the result is wanted as data, or several sites are being compared at once. The AgentReady view also calls this tool to run its own scan. Read-only: it fetches only public pages of the site named in the call and changes nothing on it.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe site to scan. A bare hostname like stripe.com works.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
scoreYesAgent-readiness score, 0-100.
limitedYesTrue when bot protection blocked so much that the headline score is not meaningful; the per-check breakdown still is.
cleanUrlYesHostname and path scanned, e.g. stripe.com.
topFixesYesFixes ranked by the points each would recover.
scannedAtYesWhen the scan finished, Unix milliseconds.
categoriesYesThe five weighted categories and their 21 checks.
protectionYesBot protection on the homepage, or null when there is none.
scannedUrlYesThe absolute URL that was fetched.
projectedScoreYesThe score the site would reach with the top fixes applied.
unverifiedCountYesChecks that could not be verified, e.g. behind bot protection.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses failure modes (limited: true when bot protection blocks, ok: false with errorType values), the side-effect-free nature ('fetches only public pages and changes nothing'), and the meaning of the score when limited. This fully informs the agent of behavioral expectations without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place: it covers purpose, categories, return structure, edge cases, and usage comparison. It is front-loaded with the core action and progressively adds detail, though the length could be trimmed slightly without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the existence of an output schema, the description comprehensively explains the return structure (score, per-category breakdown, top fixes), the limited flag semantics, and errorType values. Combined with the usage guidance and parameter hint, nothing an agent needs to call and interpret the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already describes the url parameter. The description adds a practical hint ('A bare hostname like stripe.com works') and clarifies that the tool scans a single site, which aids correct invocation. This exceeds the baseline of 3 because it gives input-format guidance not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 ('Runs the AgentReady scan on one site and returns the raw result, with no view'), which clearly distinguishes it from the sibling agent_ready that presents a visual report. It also enumerates the 21 checks across five categories, making the scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool instead of agent_ready: 'this tool fits the cases a view does not: the result is wanted as data, or several sites are being compared at once.' It also notes that the AgentReady view calls this tool internally, clarifying the orchestration relationship.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

contact_formOpen Contact FormA
Read-only
Inspect

Opens Enpitech's contact form as a view in the conversation, where the user types their own name, email and message, plus an optional phone number and company, and submits it. Use it when the user wants to get in touch with Enpitech about frontend engineering work: frontend is the bottleneck their releases wait on; AI-generated frontend code their team cannot safely merge; senior React engineers embedded in a product team; AI features, an MCP app, or an agent-ready interface built into their product; private training for their team on AI-assisted frontend delivery or Claude Code; hosting, sponsoring or speaking at a frontend meetup. It opens a form and answers no questions. The tool itself sends nothing: it returns the contact surface the form opened on, and the enquiry is sent by submit_contact when the user submits.

ParametersJSON Schema
NameRequiredDescriptionDefault
originNoWhich contact surface to open the form in, inferred from the conversation. Omit when unsure; it defaults to general. general = the user wants senior React engineers embedded in their team, a web product shipped faster, or delivery infrastructure installed so the whole org can ship frontend. factory = the conversation is specifically about the Frontend Delivery Factory as a named service: the delivery pipeline, the review load, or AI-generated frontend code the team cannot safely merge. community = the user wants to host a frontend meetup, offer a venue, sponsor, or speak. workshops = the user wants private hands-on training for their team on AI-assisted frontend delivery or Claude Code. ai-hub = the user wants AI built into their product, MCP apps, or agent-ready interfaces. agent-ready = the enquiry follows an AgentReady scan of the user's own site; the scanner view sets this itself, so pick it only when the conversation came from a scan.general

Output Schema

ParametersJSON Schema
NameRequiredDescription
originYesThe contact surface the form opened on.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds valuable behavioral context: the tool 'answers no questions', 'sends nothing', and returns 'the contact surface the form opened on', with the enquiry handled later by submit_contact. This clarifies side effects and return semantics without contradicting 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and key constraint ('answers no questions') are front-loaded, and the long use-case list is purposeful for routing. It is wordy in places, but every sentence contributes meaning; slightly tighter phrasing would push it to 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering the safety profile and an output schema present, the description supplies everything else needed: when to use it, what it does, what it doesn't do, and which sibling handles the follow-through. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the single optional origin parameter fully documented including per-enum meanings and a default. The description adds no additional parameter-level detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-plus-resource ('Opens Enpitech's contact form as a view in the conversation') and details exactly what the user does in the form. It also distinguishes the tool from its sibling submit_contact by clarifying it only opens a form and sends nothing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit 'Use it when' list covering each target scenario for Enpitech frontend work, and explicitly contrasts with submit_contact for the actual sending. It also states a when-not ('answers no questions'), giving the agent clear routing guidance against siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

email_agentready_reportEmail AgentReady ReportA
Destructive
Inspect

Emails the full 21-point AgentReady report for a site that has already been scanned, and stores the submitted name, email, phone and company as a sales lead in Enpitech's CRM under the agent-ready origin. The AgentReady view calls this tool when the user fills in the report form on the results page; it is not offered to the model. The scan is re-run server-side before the report is rendered, so the emailed report reflects the site at send time. Returns success with an emailed flag, which is false when the lead was stored but the email did not go out.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNo
nameYes
emailYes
phoneNo
scoreNo
companyNameNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
emailedNoFalse when the request was stored but the email did not go out; the view then offers a PDF instead.
successYesTrue when the request was stored.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description discloses the server-side re-scan, the emailed flag semantics (false when lead stored but email fails), and the CRM side effect. This gives a complete picture of the tool's behavior and potential partial failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: main action, usage context, then behavioral detail. Each sentence adds necessary information without repetition or fluff, making it concise and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema likely describes the return object, the description covers the key side effect (CRM lead), the freshness behavior (re-scan), and the email flag nuances. It is self-contained for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions name, email, phone, and company as lead fields, but omits url and score entirely, leaving their purpose unclear. Partial compensation is provided but incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool emails the full 21-point AgentReady report for an already-scanned site and stores lead info in CRM. It differentiates itself from siblings by noting it is not offered to the model, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use context (called by the AgentReady view on form submission) and a clear exclusion (not offered to the model). It also implies the prerequisite that the site has already been scanned, guiding appropriate invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

newsletterOpen Newsletter SignupA
Read-only
Inspect

Opens a signup form for the Enpitech newsletter, about frontend, AI and how teams ship, as a view in the conversation. The user types their own email and subscribes there. Use it when the user asks to subscribe to, join or get the Enpitech newsletter. It opens a form and subscribes no one: the subscription happens only when the user submits the form.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the readOnlyHint annotation by explicitly stating that the tool 'subscribes no one' and that subscription happens only when the user submits the form. It also discloses that the user types their own email, making the read-only interaction model clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the core action, and every sentence adds useful context. The final sentence reinforces the critical no-side-effect behavior without bloating the text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with annotations and an output schema, the description covers the action, trigger, user interaction, and side-effect guarantee. It could be slightly more complete by explicitly naming subscribe_newsletter as the alternative for direct subscription, but the current wording already bridges most ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description appropriately clarifies that the email is entered by the user in the rendered form, not passed as a tool parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: it 'opens a signup form for the Enpitech newsletter' as a view in the conversation. It also disambiguates itself from siblings by clarifying that it 'subscribes no one', which separates it from subscribe_newsletter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger conditions: 'when the user asks to subscribe to, join or get the Enpitech newsletter.' It does not explicitly name an alternative like subscribe_newsletter or state when not to use this tool, so it stops short of a perfect 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submit_contactSend EnquiryAInspect

Sends a contact enquiry to Enpitech, storing the submitted name, email, message and optional phone and company as a sales lead in Enpitech's CRM, tagged with the origin surface. The contact form view calls this tool when the user submits the form; it can also be called directly once the user has given those details in the conversation. Every field carries a value the user actually supplied; contact_form opens the same form as a view for the user to fill in when a detail is missing.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
emailYes
phoneNo
originNoWhich contact surface to open the form in, inferred from the conversation. Omit when unsure; it defaults to general. general = the user wants senior React engineers embedded in their team, a web product shipped faster, or delivery infrastructure installed so the whole org can ship frontend. factory = the conversation is specifically about the Frontend Delivery Factory as a named service: the delivery pipeline, the review load, or AI-generated frontend code the team cannot safely merge. community = the user wants to host a frontend meetup, offer a venue, sponsor, or speak. workshops = the user wants private hands-on training for their team on AI-assisted frontend delivery or Claude Code. ai-hub = the user wants AI built into their product, MCP apps, or agent-ready interfaces. agent-ready = the enquiry follows an AgentReady scan of the user's own site; the scanner view sets this itself, so pick it only when the conversation came from a scan.general
messageYes
companyNameNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
successYesTrue when the enquiry was sent.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as non-read, non-idempotent, and non-destructive. The description adds meaningful context: it stores a sales lead in the CRM, tags it with the origin surface, and enforces that every field carries a user-supplied value. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose and then usage guidance. Every sentence earns its place, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, and the relationship to contact_form. The output schema exists, so return values need not be described. Minor gaps like error behavior or prerequisites are acceptable for a straightforward form submission tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 17% (only origin has a description). The description mentions 'name, email, message and optional phone and company' but does not explain constraints or semantics for phone, companyName, or message length. It relies on the schema for origin and leaves the other parameters under-documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Sends a contact enquiry to Enpitech, storing the submitted name, email, message and optional phone and company as a sales lead in Enpitech's CRM'. It clearly distinguishes itself from contact_form by positioning that sibling as the view for filling in missing details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to call this tool ('contact form view calls this tool when the user submits the form; it can also be called directly once the user has given those details in the conversation') and when to use the alternative contact_form ('when a detail is missing'). This is direct, actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

subscribe_newsletterSubscribe to NewsletterAInspect

Subscribes the email address the user typed into the newsletter signup view to the Enpitech newsletter, managed in Mailchimp. The newsletter view calls this tool when the user submits the form; it is not offered to the model. Returns success with a status of subscribed, or pending when a confirmation email was sent first. Every newsletter email carries an unsubscribe link.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailYesThe email address the user typed into the signup form.

Output Schema

ParametersJSON Schema
NameRequiredDescription
statusNosubscribed, or pending when a confirmation email was sent first.
successYesTrue when the signup went through.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds useful behavior beyond the annotations: it discloses that the result can be 'subscribed' or 'pending' depending on whether a confirmation email is sent first, and notes that every newsletter email includes an unsubscribe link. This gives an agent a realistic picture of side effects without contradicting 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three focused sentences: what the tool does, when it is invoked, and what outcomes/features to expect. Every sentence adds value, and the purpose is front-loaded rather than buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one well-documented parameter, an output schema, and annotations present, the description provides all necessary context: invocation origin, model non-availability, possible statuses, and a compliance note. Nothing an agent needs to correctly understand this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the only parameter ('email') with full coverage, so the description does not need to add much. The description restates that the email comes from the signup form, but it does not add constraints, formats, or edge-case guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it subscribes the signup-view email to the Enpitech newsletter via Mailchimp. It also clarifies the tool's role by saying it is called by the newsletter view and not offered to the model, which differentiates it from the sibling 'newsletter' tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when the tool is invoked ('when the user submits the form') and that it is not offered to the model. It does not name alternative tools or give a when-not-to-use comparison, but the invocation context is clear enough for an agent to avoid selecting it directly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updates
    • Changedagent_ready1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "url": {
+      "description": "The site the scanner opened with, or an empty string when the user will type one in the view.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "url"
+  ],
+  "type": "object"
+}
    • Changedagentready_scan1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "categories": {
+      "description": "The five weighted categories and their 21 checks.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "checks": {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "categoryId": {
+                  "$ref": "#/properties/categories/items/properties/id"
+                },
+                "id": {
+                  "type": "string"
+                },
+                "note": {
+                  "description": "Short evidence, e.g. \"1,204 URLs\" or \"404 · missing\".",
+                  "type": "string"
+                },
+                "state": {
+                  "description": "pass, partial (counts as half) or fail; unknown means it could not be verified and is left out of the score.",
+                  "enum": [
+                    "pass",
+                    "partial",
+                    "fail",
+                    "unknown"
+                  ],
+                  "type": "string"
+                }
+              },
+              "required": [
+                "id",
+                "categoryId",
+                "state",
+                "note"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "id": {
+            "enum": [
+              "discovery",
+              "readable",
+              "structured",
+              "actions",
+              "trust"
+            ],
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "num": {
+            "description": "Display number, e.g. \"01\".",
+            "type": "string"
+          },
+          "passCount": {
+            "type": "number"
+          },
+          "score": {
+            "description": "Category score, 0-100.",
+            "type": "number"
+          },
+          "total": {
+            "type": "number"
+          },
+          "unknownCount": {
+            "description": "Checks that could not be verified, excluded from score.",
+            "type": "number"
+          },
+          "weight": {
+            "description": "Percent of the overall score; the five sum to 100.",
+            "type": "number"
+          },
+          "why": {
+            "description": "Why the category matters to AI agents.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "num",
+          "name",
+          "weight",
+          "why",
+          "score",
+          "passCount",
+          "total",
+          "unknownCount",
+          "checks"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "cleanUrl": {
+      "description": "Hostname and path scanned, e.g. stripe.com.",
+      "type": "string"
+    },
+    "limited": {
+      "description": "True when bot protection blocked so much that the headline score is not meaningful; the per-check breakdown still is.",
+      "type": "boolean"
+    },
+    "ok": {
+      "const": true,
+      "type": "boolean"
+    },
+    "projectedScore": {
+      "description": "The score the site would reach with the top fixes applied.",
+      "type": "number"
+    },
+    "protection": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "vendor": {
+              "description": "Bot protection detected, e.g. \"Cloudflare\".",
+              "type": "string"
+            },
+            "via": {
+              "description": "The signal it was detected by.",
+              "type": "string"
+            }
+          },
+          "required": [
+            "vendor",
+            "via"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Bot protection on the homepage, or null when there is none."
+    },
+    "scannedAt": {
+      "description": "When the scan finished, Unix milliseconds.",
+      "type": "number"
+    },
+    "scannedUrl": {
+      "description": "The absolute URL that was fetched.",
+      "type": "string"
+    },
+    "score": {
+      "description": "Agent-readiness score, 0-100.",
+      "type": "number"
+    },
+    "topFixes": {
+      "description": "Fixes ranked by the points each would recover.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "body": {
+            "type": "string"
+          },
+          "checkId": {
+            "type": "string"
+          },
+          "impact": {
+            "description": "Points the overall score would gain if this check passed.",
+            "type": "number"
+          },
+          "rank": {
+            "type": "number"
+          },
+          "tag": {
+            "description": "Category and weight, e.g. \"ACTIONS & MCP · 30%\".",
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "checkId",
+          "rank",
+          "title",
+          "body",
+          "tag",
+          "impact"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "unverifiedCount": {
+      "description": "Checks that could not be verified, e.g. behind bot protection.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "ok",
+    "cleanUrl",
+    "scannedUrl",
+    "score",
+    "projectedScore",
+    "categories",
+    "topFixes",
+    "unverifiedCount",
+    "limited",
+    "protection",
+    "scannedAt"
+  ],
+  "type": "object"
+}
    • Changedai_hub_search1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "category": {
+      "enum": [
+        "skills",
+        "tools",
+        "workflows"
+      ],
+      "type": "string"
+    },
+    "query": {
+      "description": "The search terms, or empty when listing.",
+      "type": "string"
+    },
+    "results": {
+      "description": "Best matches first.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "category": {
+            "enum": [
+              "skills",
+              "tools",
+              "workflows"
+            ],
+            "type": "string"
+          },
+          "install": {
+            "description": "Install command, when the item has one.",
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "overview": {
+            "type": "string"
+          },
+          "section": {
+            "description": "The catalog section it sits in.",
+            "type": "string"
+          },
+          "summary": {
+            "description": "One-line take from Enpitech.",
+            "type": "string"
+          },
+          "url": {
+            "description": "The item page on enpitech.dev.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "category",
+          "section",
+          "summary",
+          "overview",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "description": "How many catalog items matched in all.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "query",
+    "total",
+    "results"
+  ],
+  "type": "object"
+}
    • Changedcontact_form1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "origin": {
+      "description": "The contact surface the form opened on.",
+      "enum": [
+        "general",
+        "factory",
+        "community",
+        "workshops",
+        "ai-hub",
+        "agent-ready"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "origin"
+  ],
+  "type": "object"
+}
    • Changedemail_agentready_report1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "emailed": {
+      "description": "False when the request was stored but the email did not go out; the view then offers a PDF instead.",
+      "type": "boolean"
+    },
+    "success": {
+      "description": "True when the request was stored.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
    • Changednewsletter1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {},
+  "type": "object"
+}
    • Changedsubmit_contact1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "success": {
+      "description": "True when the enquiry was sent.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
    • Changedsubscribe_newsletter1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "status": {
+      "description": "subscribed, or pending when a confirmation email was sent first.",
+      "enum": [
+        "subscribed",
+        "pending"
+      ],
+      "type": "string"
+    },
+    "success": {
+      "description": "True when the signup went through.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
  2. 3 tool updates
    • Addedai_hub_search
    • Addednewsletter
    • Addedsubscribe_newsletter
  3. 5 tool updates
    • First observedagent_ready
    • First observedagentready_scan
    • First observedcontact_form
    • First observedemail_agentready_report
    • First observedsubmit_contact

Related MCP Connectors

Related MCP Servers

  • ASO Score MCP by forgemeshlabs

    ASO Score MCPofficial

    forgemeshlabs
    A
    license
    A
    quality
    A
    maintenance
    Scans websites to evaluate agent-readiness and produce an ASO Score Report across 34 signals, helping improve discoverability, trust, and interoperability for AI agents.
    4
    5
    66 npm
    1
    MIT

  • AI Product Index

    110kc3
    F
    license
    Not graded
    quality
    A
    maintenance
    Machine-readable directory of AI products that register themselves, plus an agent-readability grader for any URL.
    1
    -
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources