Enpitech

Send Enquiry

submit_contact

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`email`	Yes
`phone`	No
`origin`	No	Which 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
`message`	Yes
`companyName`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`success`	Yes	True when the enquiry was sent.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

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"
+}

First observedSep 26, 2026

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.

All Enpitech tools Inspect

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

Need Help?