Skip to main content
Glama

Open Contact Form

contact_form
Read-only

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.

Input Schema

TableJSON 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

TableJSON Schema
NameRequiredDescriptionDefault
originYesThe contact surface the form opened on.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema 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"
      +}
  2. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources