Skip to main content
Glama

L&T MCP

by ai.lntcs.beta

Server Details

This is the mcp server of L&T

Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Glama MCP Gateway

Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.

MCP client
Glama
MCP server

Full call logging

Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.

Tool access control

Enable or disable individual tools per connector, so you decide what your agents can and cannot do.

Managed credentials

Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.

Usage analytics

See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.

100% free. Your data is private.

Tool Definition Quality

B3.4/5.0
Tool DescriptionsA

Average 4.3/5 across 10 of 10 tools scored. Lowest: 3.6/5.

Server CoherenceC
Disambiguation2/5

Six of the ten tools are email-related (how_to_send_lnt_email, lnt_email_brand_guidelines, lnt_invoice_format, send_formatted_email_guide, send_invoice_email_guide, send_mail) with overlapping purposes, making it hard for an agent to distinguish when to use each. The remaining tools cover distinct functions but are few.

Naming Consistency1/5

Naming is highly inconsistent: mixing snake_case (cprs_getpurchasetypes, send_mail), camelCase (postInvActionList), and descriptive phrases (how_to_send_lnt_email). No uniform verb_noun pattern.

Tool Count3/5

The count of 10 is reasonable, but many are passive skill guides rather than actionable tools. Only 4 perform actual operations, leading to a disproportionate skill-to-action ratio.

Completeness2/5

The advertised purchase requisition workflow requires 14 steps, but only 2 are supported by actual tools. Email-related tools lack formatting generation and rely on guides. Critical operations like creating a document are missing.

Available Tools

10 tools
cprs_getpurchasetypesAInspect

[ONE LINE — what this API does]

This API retrieves a list of available purchase types for a specified company.

Use when: You need to obtain detailed information about different purchase types, such as when setting up purchase orders or managing inventory categories within the enterprise system.

IMPORTANT: Ensure that the intUID and intCompanyCode fields in the request body are correctly specified to match the user's identity and company context. These fields are essential for downstream processes that depend on accurate user and company identification.

Headers required (auto-injected by MCP server — agent does not need to manage):

  • accept: Specifies the media types that are acceptable for the response.

  • accept-language: Indicates the preferred language for the response.

  • accessflag: Used for internal access control.

  • authorization: Authentication token for secure access.

  • companycode: Identifies the company context for the request.

  • content-type: Indicates the media type of the request body.

  • delegateduserid: Represents the user ID of the delegated user.

  • doptcode: Operational code for the request.

  • dtcode: Specific code for transaction identification.

  • identifiers: Unique identifiers for the request.

  • isinternaluser: Indicates if the user is internal.

  • ismobileapp: Specifies if the request is from a mobile app.

  • loginauditno: Audit number for login tracking.

  • origin: Origin URL of the request.

  • priority: Priority level of the request.

  • sec-ch-ua: User agent client hints for browser information.

  • sec-ch-ua-mobile: Indicates if the request is from a mobile device.

  • sec-ch-ua-platform: Platform information of the user agent.

  • sec-fetch-dest: Destination of the fetch request.

  • sec-fetch-mode: Mode of the fetch request.

  • sec-fetch-site: Site context of the fetch request.

  • showspinner: Controls the display of loading indicators.

  • user-agent: Information about the user agent making the request.

  • userid: Unique identifier for the user making the request.

Request body fields:

  • intUID (integer): The unique identifier for the user making the request.

  • intCompanyCode (integer): The code representing the company for which purchase types are being requested.

  • chrActiveStatus (string): Indicates whether to fetch active purchase types ('Y' for active).

Response fields:

  • result.typeLists (array): Contains detailed information about each purchase type.

    • purchaseTypeCode (integer): The unique code identifying the purchase type.

    • purchaseTypeDesc (string): A full description of the purchase type.

    • purchaseTypeShortDesc (string): A shortened description of the purchase type.

    • purchaseActive (string): Indicates if the purchase type is currently active ('Y' for active).

Error handling:

  • If the request fails due to authorization issues, ensure the authorization header is correctly set.

  • If no purchase types are returned, verify that the intCompanyCode and chrActiveStatus in the request body are correct and correspond to valid entries in the system.

  • Network or server errors may result in a null or empty response; retry the request or check server status.

ParametersJSON Schema
NameRequiredDescriptionDefault
request_bodyYesRequest body imported from cURL. Content-Type: application/json. Template/example: {

Tool Definition Quality

A4.4/5.0
Behavior4/5

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

No annotations, so description carries burden. States it retrieves data, lists headers (auto-injected), request body, response fields, and error handling. No side effects disclosed, but retrieval is clear.

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

Conciseness3/5

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

Well-structured with sections but very verbose, especially listing all auto-injected headers. Could be trimmed without losing value.

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 no output schema, description covers request body, response structure, and error handling. For a simple list tool, it is complete.

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

Parameters5/5

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

Input schema only has truncated 'request_body' param. Description adds three specific fields (intUID, intCompanyCode, chrActiveStatus) with types and descriptions, greatly enhancing meaning.

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?

Clear verb 'retrieves' and resource 'purchase types for a specified company'. Distinct from sibling tools which are email-related.

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?

Explicit 'Use when' context (setting up purchase orders, managing inventory categories) but no mention of 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.

cprsorm_getjobbasedwhlistAInspect

Tool Name: cprsorm_getjobbasedwhlist

Description: Retrieves the list of warehouses linked to a specific job/project code in L&T's CPR ORM module. Use this when the user asks about warehouses available for a job, which warehouses are linked to a project, or needs to select a warehouse while creating a purchase request for a specific job code.

Request schema:

  • strJobcode (str): REQUIRED — Job/project code to fetch warehouses for e.g. "LE20M143". Ask the user for this if not provided.

  • intCompanyCode (int): REQUIRED — Company code, always use 1 for L&T.

  • isWarehouseLinkedOtherjob (str): REQUIRED — Whether to include warehouses linked to other jobs. Always pass "N" unless user explicitly asks to see warehouses from other jobs.

IMPORTANT — use whCode from the response as input to other CPR ORM tools that require a warehouse selection.

Response schema:

  • []: flat list of warehouses directly (no wrapper object)

    • whCode (str): unique warehouse code e.g. "3116", "6691" — pass this to downstream tools that require a warehouse code

    • whDescription (str): full warehouse name including location and code suffix e.g. "FORM WORK COMPETENCY CELL -HQ - 3116" — display this to the user when asking them to select a warehouse

Error handling:

  • If result is empty list [], inform user: "No warehouses found for job code X. Please verify the job code is correct and active."

  • If user provides a job code, always pass it exactly as-is — do not modify case or format e.g. "LE20M143" not "le20m143"

ParametersJSON Schema
NameRequiredDescriptionDefault
request_bodyYesRequest body imported from cURL. Content-Type: application/json. Template/example: {

Tool Definition Quality

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses request parameters, response format, and error handling. No contradictions.

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?

Well-structured with sections, but slightly verbose with examples and error handling. Front-loaded with purpose.

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?

No output schema, but description fully explains response format and how to use output. Complete for the tool's complexity.

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

Parameters5/5

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

Despite vague schema, the description details all parameters (strJobcode, intCompanyCode, isWarehouseLinkedOtherjob) with values and usage, compensating fully.

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 clearly states it retrieves warehouses linked to a job/project code, with examples of user queries. It distinguishes from sibling tools by mentioning downstream warehouse requirements.

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?

Explicit when-to-use with examples and error handling, but no explicit when-not-to-use. Alternatives are implied but not named.

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

cprs_requisition_workflowAInspect

SKILL: cprs_requisition_workflow Team: SCM , CPRS

CPRS Purchase Requisition — Creation Workflow

Call this tool to get the complete guide for 'cprs_requisition_workflow'. Read the 'content' field and follow its instructions. This tool takes NO parameters.

Full content:

name: cprs_requisition_workflow description: Step-by-step guide for creating a CPRS Purchase Requisition using EIP APIs

CPRS Purchase Requisition — Creation Workflow

Use this skill when a user wants to raise a Capital Purchase Requisition (CPRS) in EIP. This is a 14-step sequential workflow. Each step must be completed before the next.

When to Use

  • User says "create a CPRS", "raise a purchase requisition", "I need to buy equipment"

  • User mentions job codes, asset groups, or purchase types

Step-by-Step Flow

Step 1 — Search Job Details

Tool: cprs_advancesearchjobdetails Ask the user for their Job Code or search by user ID. Returns a list of active jobs the user can raise requisitions against. Store: job_code, dtCode, doptCode, companyCode

Step 2 — Get Request Category

Tool: cprs_awmreqcategory Uses the job code from Step 1. Returns available request categories for that job. Store: categoryCode, subCategoryCode

Step 3 — Get Purchase Types

Tool: cprs_getpurchasetypes Returns CAPEX, OPEX, Lease options available to the user. Ask the user to select one. Store: purchaseTypeCode, purchaseTypeName

Step 4 — Fetch Capital Sanction Listing

Tool: cprs_postfetchcslisting Automatic — no user input needed. Fetches budget sanction details for the job. Store: finYear, csData

Step 5 — Get Asset Group Codes

Tool: cprs_getassetgroupcodedetails Returns asset groups available for the selected category. Ask the user to select an asset group (e.g. P&M, IT Equipment). Store: groupCode, groupDesc

Step 6 — Currency Conversion

Tool: cprs_currencyconvertion Automatic — fetches INR conversion rate. Store: conversionRate

Step 7 — Get Asset Master by Group

Tool: cprsorm_getassetmasterbygroup Automatic — fetches asset details for the selected group.

Step 8 — Get Asset Make by Group

Tool: cprsorm_getassetmakebygroup Returns manufacturer list (Dell, HP, Lenovo etc). Ask user to select a make. Store: assetMakeCode, assetMakeDesc

Step 9 — Get Asset Model by Make

Tool: cprsorm_getassetmodelbymake Returns models for the selected make. Ask user to select a model. Store: assetModelCode, assetModelDesc

Step 10 — Get Job-Based Warehouse List

Tool: cprsorm_getjobbasedwhlist Returns warehouses linked to the job for delivery. Ask user to select delivery warehouse. Store: warehouseCode, warehouseName

Step 11 — Check Equipment Availability (PHRS)

Tool: cprsorm_phrsequimentavailabilitystatus Automatic — checks if equipment already available within L&T. Show result to user. If available, suggest using existing stock.

Step 12 — Get AMS Surplus Details

Tool: cprs_getamssurplusdetails Automatic — checks surplus assets available. Show result to user.

Step 13 — Get Procurement Reason List

Tool: cprsorm_getprocurementreasonlist Returns justification reasons for procurement. Ask user to select a reason. Store: procJustificationCode

Step 14 — Create CPRS Document

Tool: cprs_documentcreate Final submission. Assembles all collected data and creates the requisition. Show confirmation summary to user before submitting. Returns: cprsNumber, approval routing details

Data Flow Summary

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Tool Definition Quality

A4.6/5.0
Behavior5/5

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

No annotations are provided, so description carries full burden. It transparently describes the tool as returning a guide with no side effects, parameters, or destructive actions. No contradictions.

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 lengthy because it includes the full workflow guide, but key info is front-loaded (purpose, no params). Every part serves a purpose as it is the tool's output. Could be slightly trimmed, but acceptable for a static guide tool.

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 no annotations, no output schema, and zero parameters, the description fully compensates by providing a complete workflow, usage examples, and detailed steps. The agent has everything needed to use this tool correctly.

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?

Zero parameters. Description explicitly states 'This tool takes NO parameters.' Baseline for 0 params is 4. Schema coverage is 100% (empty schema), so no additional param info needed.

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?

Description clearly states the tool provides a step-by-step guide for creating a CPRS Purchase Requisition. It specifies 'Call this tool to get the complete guide' and distinguishes from sibling tools (individual steps like cprs_getpurchasetypes). Verb+resource+scope are explicit.

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?

Includes a 'When to Use' section with example user phrases, and context implies this is the entry point to the workflow. However, it does not explicitly state when not to use or mention alternative tools, but the guidance is clear enough for an agent.

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

how_to_send_lnt_emailAInspect

SKILL: how_to_send_lnt_email Team: platform

How to Send an L&T Branded Email

Call this tool to get the complete guide for 'how_to_send_lnt_email'. Read the 'content' field and follow its instructions. This tool takes NO parameters.

Full content:

name: how_to_send_lnt_email description: Instructions for sending L&T branded emails — explains exactly what steps to follow and which tools to call

How to Send an L&T Branded Email

Follow these exact steps whenever a user wants to send any information by email.

When to Use This Guide

  • User says "send this to [email]"

  • User says "email this to [name]"

  • User says "mail the results to..."

  • User wants to share any data or information via email

Step 1 — Collect These 5 Things

Ask the user for anything missing:

  1. Recipient email address — where to send

  2. Recipient name — for the greeting "Dear [name],"

  3. Sender name — for the signature "Warm regards, [name]"

  4. Subject line — or derive it from the content

  5. Email content — what to put in the body

Do not proceed until you have all 5.

Step 2 — Read the Brand Guidelines

Call the lnt_email_brand_guidelines tool (no arguments needed). Read the returned content carefully. Use those guidelines to generate the complete HTML email yourself.

Build the HTML with:

  • Navy header + orange accent bar

  • "Dear [recipient name],"

  • Body content formatted as paragraphs or table

  • "Warm regards, [sender name]" signature

  • Gray footer with confidential notice

Step 3 — Send the Email

Call the send_email tool with this exact JSON:

{
  "personalizations": [
    {
      "to": [{"email": "RECIPIENT_EMAIL_HERE"}],
      "subject": "SUBJECT_HERE"
    }
  ],
  "from": {"email": "lntcs@lntecc.com"},
  "content": [
    {
      "type": "text/html",
      "value": "YOUR_GENERATED_HTML_HERE"
    }
  ]
}
Step 4 — Confirm to User
On success: "✅ Email sent to [name] at [email]."
On failure: "❌ Could not send. Error: [message]."

Important Rules
NEVER call lnt_email_brand_guidelines with arguments — it takes none
NEVER send plain text — always generate and send HTML
From address is ALWAYS lntcs@lntecc.com — never change this
Generate the HTML yourself — do not look for an HTML generation tool
Subject must be specific and descriptive
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Tool Definition Quality

A4.4/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It fully discloses that the tool returns a guide (a read operation) and includes all instructions. There is no hidden side effect or destructive behavior. The content is transparent and comprehensive.

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

Conciseness3/5

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

The description is very long as it includes the full guide content. While the content is relevant, it could be summarized more concisely (e.g., 'Returns complete instructions for sending branded email'). The structure with headings is clear, but the length reduces conciseness.

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?

Given no output schema, the description explains that the return has a 'content' field to read. It provides the complete guide content, so the user knows exactly what to expect. However, it does not specify the exact output structure (e.g., if there are other fields), which would fully complete the context.

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 input schema has zero parameters, and the description explicitly states 'This tool takes NO parameters.' Since schema coverage is trivially 100%, the baseline is 4. The description adds no param info because none is needed, and it clarifies the absence of parameters.

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 'Call this tool to get the complete guide for how_to_send_lnt_email' and follows with a detailed guide. It clearly identifies the tool as providing step-by-step instructions for sending branded emails, distinguishing it from siblings like send_mail or lnt_email_brand_guidelines that perform different actions.

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 includes a 'When to Use This Guide' section listing specific user utterances that trigger usage (e.g., 'send this to [email]'). It provides clear context for when to invoke the tool. However, it does not explicitly mention when not to use it or compare with sibling tools like send_formatted_email_guide, which could be an alternative.

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

lnt_email_brand_guidelinesAInspect

SKILL: lnt_email_brand_guidelines Team: Platform

L&T Email Brand Guidelines

Call this tool to get the complete guide for 'lnt_email_brand_guidelines'. Read the 'content' field and follow its instructions. This tool takes NO parameters.

Full content:

name: lnt_email_brand_guidelines description: L&T brand guidelines for email formatting — reference document, not a function to call with parameters

L&T Email Brand Guidelines

This is a REFERENCE DOCUMENT. Read it and use the guidelines to construct emails yourself. Do NOT call this with any arguments — it takes no parameters.

Brand Colors

  • Primary Navy: #002B5C

  • Accent Orange: #F47B20

  • Body text: #374151

  • Light background: #f8fafc

Email Structure

1. Header Block

  • Background: #002B5C (navy)

  • White bold text: "L&T Construction"

  • Subtitle: "EIP Cognitive Services Platform" in rgba(255,255,255,0.65)

  • Top right: orange badge (#F47B20) with text "MCP AGENT"

  • Below header: 4px solid orange line (#F47B20)

2. Greeting

  • "Dear [RECIPIENT_NAME],"

  • Color: #002B5C, bold, font-size: 16px

  • Padding: 32px top and sides

3. Body Content

  • Font-size: 14px, color: #374151, line-height: 1.7

  • Padding: 12px 32px 24px 32px

  • For plain text: wrap each paragraph in p tags with margin-bottom: 12px

  • For structured data: use a table with navy (#002B5C) header row, white text, alternating white and #f8fafc rows

  • End with: "Please feel free to reach out if you need any clarification."

4. Divider

  • 1px solid #e5e7eb horizontal line

5. Signature Block

  • "Warm regards," in #374151

  • Sender name in bold #002B5C, font-size: 15px

  • "L&T Construction — EIP Cognitive Services" in #64748b, font-size: 12px

  • Padding: 20px 32px

6. Footer Block

  • Background: #f8fafc

  • Border-top: 1px solid #e5e7eb

  • Centered text, font-size: 11px, color: #9ca3af

  • Line 1: "This email was generated by the L&T MCP Agent Platform."

  • Line 2: "Larsen & Toubro Limited · Construction Division · EIP Cognitive Services"

  • Line 3: Orange square ■ + "Confidential — For intended recipient only"

HTML Wrapper

  • Full document: to

  • Body background: #f4f4f4

  • Center everything in a 620px wide white table

  • White card with box-shadow: 0 2px 8px rgba(0,0,0,0.08)

  • Border-radius: 8px

  • All CSS must be inline — no external stylesheets

Key Rules

  • From address is ALWAYS lntcs@lntecc.com

  • Always generate complete valid HTML

  • Orange accent bar between header and body is mandatory

  • Generate the HTML yourself from these guidelines — do not call any tool for HTML generation

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Tool Definition Quality

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses the tool's behavior: it is a read-only reference document that returns content. It details the structure and content of the returned guidelines, leaving no ambiguity about side effects or requirements.

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

Conciseness3/5

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

The description is verbose and contains redundant statements (e.g., multiple mentions of 'no parameters'). It includes a 'Full content' section that essentially duplicates the initial description. While structured with headings, it could be more concise.

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 reference document tool with no parameters and no output schema, the description is complete. It explains the tool's purpose, the content it returns, and how to use the information. The sibling tools provide context for alternative actions like sending emails.

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 the schema coverage is 100%. The description adds value by explicitly stating it takes no parameters and repeating the instruction not to call with arguments. This clarifies the intended usage 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 clearly identifies the tool as a reference document for L&T email brand guidelines, using specific verbs like 'get the complete guide'. It distinguishes itself from sibling tools like 'send_mail' by stating it is not a function to call with parameters but a guide to follow.

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 to use the tool ('Call this tool to get the complete guide') and what not to do ('Do NOT call this with any arguments'). It implies context by mentioning the guidelines are for constructing emails, fitting with siblings that send emails. However, it does not explicitly mention alternatives or when not to use it.

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

lnt_invoice_formatAInspect

SKILL: lnt_invoice_format Team: Finance ,SCM

name: lnt_invoice_format

Call this tool to get the complete guide for 'lnt_invoice_format'. Read the 'content' field and follow its instructions. This tool takes NO parameters.

Full content: name: lnt_invoice_format description: Format invoice data into L&T branded HTML email template L&T Invoice Email Formatter Fields You Need Just these 8 fields:

invoice_number invoice_date due_date vendor_name po_number project_code total payment_status HTML Template Replace all {{PLACEHOLDER}} with actual values.

html Copy

      <!-- HEADER -->
      <tr>
        <td style="background-color:#002B5C;padding:24px 32px;">
          <div style="color:#ffffff;font-size:22px;font-weight:bold;">
            L&T Construction
          </div>
          <div style="color:#F47B20;font-size:11px;margin-top:4px;letter-spacing:2px;">
            ENTERPRISE INFORMATION PLATFORM
          </div>
        </td>
      </tr>

      <!-- ORANGE BAR -->
      <tr>
        <td style="background-color:#F47B20;height:4px;"></td>
      </tr>

      <!-- TITLE ROW -->
      <tr>
        <td style="padding:28px 32px 16px 32px;">
          <table width="100%" cellpadding="0" cellspacing="0">
            <tr>
              <td>
                <div style="font-size:20px;font-weight:bold;color:#002B5C;">
                  INVOICE SUMMARY
                </div>
                <div style="font-size:12px;color:#888888;margin-top:4px;">
                  Auto-generated by L&T EIP MCP Agent
                </div>
              </td>
              <td align="right">
                <div style="background-color:{{STATUS_COLOR}};color:#ffffff;
                            padding:8px 16px;border-radius:4px;
                            font-size:13px;font-weight:bold;">
                  {{PAYMENT_STATUS}}
                </div>
              </td>
            </tr>
          </table>
        </td>
      </tr>

      <!-- DIVIDER -->
      <tr>
        <td style="padding:0 32px;">
          <hr style="border:none;border-top:1px solid #eeeeee;">
        </td>
      </tr>

      <!-- INVOICE DETAILS -->
      <tr>
        <td style="padding:24px 32px;">
          <table width="100%" cellpadding="0" cellspacing="0">

            <tr>
              <td width="50%" style="padding:8px 0;">
                <div style="font-size:11px;color:#999999;
                            text-transform:uppercase;font-weight:bold;">
                  Invoice Number
                </div>
                <div style="font-size:14px;color:#002B5C;
                            font-weight:bold;margin-top:4px;">
                  {{INVOICE_NUMBER}}
                </div>
              </td>
              <td width="50%" style="padding:8px 0;">
                <div style="font-size:11px;color:#999999;
                            text-transform:uppercase;font-weight:bold;">
                  PO Number
                </div>
                <div style="font-size:14px;color:#333333;margin-top:4px;">
                  {{PO_NUMBER}}
                </div>
              </td>
            </tr>

            <tr>
              <td width="50%" style="padding:8px 0;">
                <div style="font-size:11px;color:#999999;
                            text-transform:uppercase;font-weight:bold;">
                  Invoice Date
                </div>
                <div style="font-size:14px;color:#333333;margin-top:4px;">
                  {{INVOICE_DATE}}
                </div>
              </td>
              <td width="50%" style="padding:8px 0;">
                <div style="font-size:11px;color:#999999;
                            text-transform:uppercase;font-weight:bold;">
                  Due Date
                </div>
                <div style="font-size:14px;color:#333333;margin-top:4px;">
                  {{DUE_DATE}}
                </div>
              </td>
            </tr>

            <tr>
              <td width="50%" style="padding:8px 0;">
                <div style="font-size:11px;color:#999999;
                            text-transform:uppercase;font-weight:bold;">
                  Vendor Name
                </div>
                <div style="font-size:14px;color:#333333;margin-top:4px;">
                  {{VENDOR_NAME}}
                </div>
              </td>
              <td width="50%" style="padding:8px 0;">
                <div style="font-size:11px;color:#999999;
                            text-transform:uppercase;font-weight:bold;">
                  Project Code
                </div>
                <div style="font-size:14px;color:#333333;margin-top:4px;">
                  {{PROJECT_CODE}}
                </div>
              </td>
            </tr>

          </table>
        </td>
      </tr>

      <!-- TOTAL AMOUNT BOX -->
      <tr>
        <td style="padding:0 32px 28px 32px;">
          <table width="100%" cellpadding="0" cellspacing="0"
                 style="background-color:#002B5C;border-radius:6px;">
            <tr>
              <td style="padding:20px 24px;">
                <div style="font-size:12px;color:#ffffff;
                            opacity:0.7;text-transform:uppercase;
                            letter-spacing:1px;">
                  Total Invoice Amount
                </div>
                <div style="font-size:28px;color:#F47B20;
                            font-weight:bold;margin-top:6px;">
                  ₹{{TOTAL_AMOUNT}}
                </div>
              </td>
            </tr>
          </table>
        </td>
      </tr>

      <!-- SIGNATURE -->
      <tr>
        <td style="padding:0 32px 24px 32px;">
          <div style="font-size:13px;color:#333333;line-height:2;">
            Regards,<br>
            <strong style="color:#002B5C;">L&T EIP System</strong><br>
            <span style="color:#666666;font-size:12px;">
              Enterprise Information Platform — SCM Module
            </span><br>
            <span style="color:#666666;font-size:12px;">
              Larsen & Toubro Construction
            </span><br>
            <span style="color:#F47B20;font-size:11px;">
              This is an auto-generated email. Please do not reply.
            </span>
          </div>
        </td>
      </tr>

      <!-- FOOTER -->
      <tr>
        <td style="background-color:#002B5C;padding:14px 32px;">
          <table width="100%" cellpadding="0" cellspacing="0">
            <tr>
              <td style="color:#ffffff;font-size:11px;opacity:0.6;">
                © 2025 Larsen & Toubro Limited. All rights reserved.
              </td>
              <td align="right" style="color:#F47B20;font-size:11px;">
                Powered by L&T Enterprise MCP
              </td>
            </tr>
          </table>
        </td>
      </tr>

    </table>
  </td>
</tr>
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Tool Definition Quality

A4.2/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: returns a guide, takes no parameters, and includes the full content. It explicitly states 'This tool takes NO parameters' and describes the output format.

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

Conciseness2/5

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

The description is excessively long, containing the full HTML template and instructions. While front-loaded with purpose, it includes redundant detail that could be condensed. Not concise for the agent.

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 no parameters and no output schema, the description is fully complete: it explains what the guide contains, required fields, mapping, rules, and example output. No missing information.

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 with 100% schema coverage. The description adds value by explicitly stating it takes no parameters, leaving no ambiguity.

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 clearly states the tool's purpose: 'Call this tool to get the complete guide for lnt_invoice_format' and 'Format invoice data into L&T branded HTML email template'. It distinguishes from siblings like send_invoice_email_guide by specifying it provides the guide, not sending.

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

Usage Guidelines3/5

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

While the description implies usage for obtaining the formatting guide, it lacks explicit guidance on when to use this tool versus siblings (e.g., how_to_send_lnt_email, send_invoice_email_guide). No exclusions or alternatives are mentioned.

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

postInvActionListAInspect

Tool Name: postInvActionList Retrieves a list of created invoices accessible to a specified user for a given date range, filtered by company, DT code, and country. Use when: You need to fetch invoices for a specific user to perform downstream actions such as claim approval, all, approved, rejected. based on the user's access level (creator, approver, or viewer). Always use this tool first before invoking any invoice approval or processing workflows. IMPORTANT: Ensure that uid, DTCode, intCompanyCode, and CompanyCode are correctly specified to match the user's identity and company context. These fields are essential for downstream processes. Always pass jobCode from the response exactly as received — do not alter its case or format (e.g. "LE25P001", not "le25p001").

Headers required (auto-injected by MCP server — agent does not need to manage):

accept: Specifies the media types acceptable for the response. accept-language: Indicates the preferred language for the response. accessflag: Used for internal access control. authorization: Authentication token for secure access. companycode: Identifies the company context for the request. content-type: Indicates the media type of the request body. delegateduserid: Represents the user ID of the delegated user. doptcode: Operational code indicating user access mode (creator, approver, or viewer). dtcode: Specific code for DT-level transaction identification. identifiers: Unique identifiers for the request. isinternaluser: Indicates if the user is internal. ismobileapp: Specifies if the request is from a mobile app. loginauditno: Audit number for login tracking. origin: Origin URL of the request. priority: Priority level of the request. sec-fetch-dest: Destination of the fetch request. sec-fetch-mode: Mode of the fetch request. sec-fetch-site: Site context of the fetch request. showspinner: Controls the display of loading indicators. user-agent: Information about the user agent making the request. userid: Unique identifier for the user making the request.

Request body fields:

uid (integer): The unique identifier of the user accessing the invoices. fromDate (datetime, ISO 8601): Start of the date range for fetching created invoices. toDate (datetime, ISO 8601): End of the date range for fetching created invoices. actionName (string): The action context for listing invoices (e.g. "For Action - Claim Approval"). DTCode (integer): Filters invoices belonging to the specified DT code. doptCode (string): Determines the user's access mode — "S" for creator/submitter, "A" for approver, "V" for viewer. intCompanyCode (integer): Internal company code used to filter invoices. CompanyCode (integer): Company code used to filter invoices. sourceCountry (integer): Country code for the invoice source (0 = all countries).

Response fields:

invActionListDetails (array): A flat list of invoice detail objects. Key fields include:

invoiceNo / strActualInvoiceNo (string): The invoice number (e.g. "AG/PI/000001"). jobCode (string): The job code associated with the invoice — always pass exactly as returned, preserving case (e.g. "LE25P001", not "le25p001"). jobDescription (string): Full description of the job (e.g. "LE25P001 - testing_april"). orderNumber (string): Full order reference (e.g. "LE25P001/PI/0001"). docStatus (string): Current status of the invoice (e.g. "Submitted", "Approved"). invType / invTypeDescription (string): Invoice type code and label (e.g. "PI" = Progress Invoice). invGroup / invGroupDescription (string): Invoice group code and label (e.g. "AG" = Main Invoice Group). invClaimedAmt (decimal): The claimed amount on the invoice. invCertifieddAmt (decimal): The certified amount on the invoice. currencyDescription (string): Currency code for the invoice (e.g. "AED"). currencyFullDescription (string): Full currency name (e.g. "United Arab Emirates dirham"). dtMeasurementPerodFrom / dtMeasurementPerodTo (datetime): Measurement period start and end dates. intConsigneeCode (integer): Consignee reference code for the invoice. customerCode / customerDescription (string): Customer identifier and description. decTaxAmount (decimal): Tax amount applied to the invoice. irnStatus (string): IRN status flag (e.g. "N"). aggregationTag (string): Aggregation flag (e.g. "Y").

Error handling:

If invActionListDetails returns an empty list [], inform the user: "No invoices found for user [uid]. Please verify the user ID is correct and active." If the request fails due to authorization issues, ensure the authorization header is correctly set. If no invoices are returned, verify that DTCode, doptCode, intCompanyCode, and the date range are valid and correspond to existing entries in the system. Network or server errors may result in a null or empty response; retry the request or check server status.

Example request: json{ "uid": 197406, "fromDate": "2026-05-04T12:22:48.000Z", "toDate": "2026-06-03T12:22:48.000Z", "actionName": "For Action - Claim Approval", "DTCode": 30057, "doptCode": "S", "intCompanyCode": 1, "CompanyCode": 1, "sourceCountry": 0 }

ParametersJSON Schema
NameRequiredDescriptionDefault
uidNologin user id
DTCodeNoFilter invoices by this DT code
toDateNoEnd of the date range for created invoices
doptCodeNoDetermines user access mode
fromDateNoStart of the date range for created invoices
actionNameNoAction context for listing invoices
CompanyCodeNoCompany code
request_bodyYesRaw JSON request body. Content-Type: application/json. Template/example: { "uid": 30023, "fromDate": "2026-05-04T14:52:32.000Z", "toDate": "2026-06-03T14:52:32.000Z", "actionName": "All", "DTCode": 30057, "doptCode": "V", "intCompanyCode": 1, "CompanyCode": 1, "sourceCountry": 0
sourceCountryNoCountry code
intCompanyCodeNocompany code

Tool Definition Quality

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is a read-only retrieval operation, lists request and response fields, and provides error handling. While very detailed, it includes non-actionable headers (auto-injected) and some extraneous information, but overall adequately describes behavior.

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

Conciseness2/5

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

The description is overly verbose, nearly 1,500 words. It includes a long list of auto-injected headers (which the agent does not need to manage), extensive response field descriptions, and redundant error handling advice. The purpose and guidelines are front-loaded, but the rest could be drastically shortened without losing essential information.

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?

No output schema exists, so the description compensates by fully documenting the response structure, error handling, and an example request. It also explains the tool's place in the workflow (first step). However, the excessive detail on headers and lengthy field lists could be trimmed while still being complete.

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%, but the description adds significant value beyond the schema: it explains doptCode values ('S' for creator, 'A' for approver, 'V' for viewer), provides example values for many parameters, and details the response structure. However, some parameter descriptions in the schema already exist, so the addition is helpful but not transformative.

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?

Description clearly states it retrieves a list of invoices for a user filtered by date range, company, DT code, and country. It distinguishes itself from sibling tools by specifying it's the first step before invoice approval workflows, and sibling tools are unrelated (purchase types, email guides).

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?

Explicit guidance: 'Use when: You need to fetch invoices for a specific user to perform downstream actions... Always use this tool first before invoking any invoice approval or processing workflows.' Also provides error handling and parameter correctness warnings.

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

send_formatted_email_guideAInspect

SKILL: send_formatted_email_guide Team: platform

Send Formatted L&T Email

Call this tool to get the complete guide for 'send_formatted_email_guide'. Read the 'content' field and follow its instructions. This tool takes NO parameters.

Full content:

name: send_formatted_email_guide description: Master guide for sending formatted L&T emails — combines brand guidelines with send tool

Send Formatted L&T Email

When user wants to send an email:

  1. Follow the how_to_send_lnt_email guide exactly

  2. Use lnt_email_brand_guidelines for HTML formatting reference

  3. Call send_email tool to deliver

That is all. Do not overcomplicate it.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Tool Definition Quality

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the burden of transparency. It clearly indicates the tool returns guide content and instructs the agent to read the 'content' field. However, it does not explicitly state that the tool is read-only, nor does it disclose any potential side effects, permissions, or behavioral constraints.

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

Conciseness2/5

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

The description is overly verbose, repeating the tool name and including a full markdown guide that could be externalized. The front-loaded message is clear, but the redundant content makes it less concise than necessary for an AI agent.

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 simple guide tool with no parameters or output schema, the description provides complete context: it explains the tool's purpose, the content it returns, and the exact steps the agent should follow. This is adequate for the tool's complexity.

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 takes zero parameters, and the description explicitly states this ('takes NO parameters'). Schema coverage is 100%, so the description adds no additional parameter semantics beyond what the schema provides, but the clarity about no parameters is sufficient.

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

Purpose4/5

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

The description clearly states that the tool provides a guide for sending formatted L&T emails, specifying it is a 'Master guide' that combines brand guidelines with the send tool. However, it references sibling tools in the instructions, which could cause confusion about when to use this tool versus directly using those siblings.

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 explains when to call the tool ('to get the complete guide') and provides explicit step-by-step instructions for the agent to follow. It does not, however, mention alternatives or when not to use this tool, despite the presence of related sibling tools.

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

send_invoice_email_guideAInspect

SKILL: send_invoice_email_guide Team: Finance , SCM

Send Invoice Email — Agent Guide

Call this tool to get the complete guide for 'send_invoice_email_guide'. Read the 'content' field and follow its instructions. This tool takes NO parameters.

Full content:

name: send_invoice_email_guide description: Collect invoice details from user, format as L&T branded email and send it

Send Invoice Email — Agent Guide

Trigger Phrases

  • "send invoice to..."

  • "email invoice details..."

  • "share invoice with..."

  • "notify about invoice..."

Steps — Follow In Order

Step 1 — STOP. Ask The User For These Fields

NEVER assume or make up any invoice data. NEVER use example values. ALWAYS ask the user first.

Ask the user for ALL of these in one message:

I need the following invoice details to send the email:

1.  Invoice Number     (e.g. INV-2024-XXXXX)
2.  Invoice Date       (e.g. 15-Jan-2025)
3.  Due Date           (e.g. 14-Feb-2025)
4. Vendor Name        (e.g. Tata Steel Limited)
5.  PO Number          (e.g. PO-2024-XXXXX)
6. Project Code       (e.g. LE20M143)
7.  Total Amount (₹)   (e.g. 3450320)
8.  Payment Status     (Pending / Paid / Overdue / Partial)
9.  Recipient Email    (who to send this to)

Please provide all details and I will send the formatted L&T invoice email.

Wait for the user to reply with all fields before proceeding. Do NOT move to Step 2 until user has provided the data. If user skips any field → ask again for the missing ones.

Step 2 — Format Using lnt_invoice_format Skill

Read the lnt_invoice_format skill completely. Use ONLY the values the user provided in Step 1. Build the complete HTML using the template. Format total in Indian number format (e.g. 34,50,320). Set correct STATUS_COLOR based on payment_status.

Step 3 — Compose Subject

Invoice Summary — {invoice_number} | {project_code} | L&T EIP

Step 4 — Send The Email

Call send_email tool with:

from:      lntcs@lntecc.com   ← always fixed
to:        {recipient_email from Step 1}
subject:   {subject from Step 3}
html_body: {complete HTML from Step 2}

Step 5 — Confirm To User

✅ Invoice email sent successfully!

To:      {recipient_email}
Invoice: {invoice_number}
Project: {project_code}
Amount:  ₹{total formatted}
Status:  {payment_status}

Rules

  • NEVER make up invoice data — always collect from user first

  • NEVER skip Step 1

  • NEVER use example values from the skill as real data

  • Sender is ALWAYS lntcs@lntecc.com — never ask user for this

  • Only ask for 9 fields listed above — nothing more

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Tool Definition Quality

A3.7/5.0
Behavior4/5

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

No annotations provided, so the description carries full burden. It clearly explains the tool returns a guide, requires no parameters, and instructs the agent to read the 'content' field. It also provides rules (e.g., fixed sender, never ask for more than two inputs). However, the description redundantly includes the full guide content, which could confuse the agent about what the tool actually returns.

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

Conciseness2/5

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

The description is extremely verbose, including the entire guide content (multiple sections, steps, rules) inline. While structured with headings and markdown, it is not concise – it duplicates the tool's output within the description itself, which is wasteful and may confuse the agent.

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?

Given no parameters, no output schema, and no annotations, the description provides comprehensive context: the purpose, the steps to follow, parameters to collect, rules, and confirmation message. The only issue is the redundancy with the tool's return value, but the description is complete enough for the agent to use the tool correctly.

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?

No parameters exist in the input schema (100% coverage by default). The description adds meaning by explaining the tool takes no parameters and why (it's a guide retrieval tool). This exceeds the baseline of 4 for zero-parameter tools.

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 clearly states the tool's purpose: 'Call this tool to get the complete guide for send_invoice_email_guide'. It specifies a specific resource (guide for sending invoice emails) and distinguishes itself from sibling tools like how_to_send_lnt_email and send_formatted_email_guide by focusing on invoice-specific email with L&T branding.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description only says 'Call this tool to get the complete guide' without any conditions, exclusions, or mention of sibling tools. The agent receives no help in deciding between this and similar tools like send_formatted_email_guide.

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

send_mailAInspect

Sends an email to specified recipients using SendGrid's email delivery service.

Use when: "send an email", "notify user by email", "trigger email alert", "deliver notification via email", "SendGrid email", "outbound email"

IMPORTANT: Ensure the sender email address is authorized in SendGrid. If using dynamic content, verify template variables are correct. No direct cross-tool dependencies, but email content may reference data from other EIP modules.

Headers required (auto-injected):

  • Authorization: Bearer token for SendGrid API access

  • Content-Type: application/json

Request body fields:

  • personalizations: List of recipient and email metadata objects.

    • to: Array of recipient objects.

      • email: Recipient's email address.

    • subject: Subject line for the email.

  • from: Object specifying the sender.

    • email: Sender's email address.

  • content: List of content objects for the email body.

    • type: MIME type of the email content (e.g., text/plain, text/html).

    • value: Actual content of the email message.

Response fields:

  • No live response sample available. On success, the API typically returns HTTP 202 Accepted with an empty body, indicating the email was queued for delivery.

Error handling:

  • 400 Bad Request: The request body is invalid, missing required fields, or contains malformed email addresses.

  • 401 Unauthorized: The Authorization header is missing or the API key is invalid.

  • 403 Forbidden: The sender email address is not verified or not allowed.

  • 429 Too Many Requests: Rate limit exceeded.

  • 5xx Server Errors: Temporary issues with SendGrid's service.

Rules:

  • Always provide a valid, authorized sender email.

  • Ensure recipient emails are accurate.

  • If using HTML content, set type to "text/html".

  • Handle 202 response as success; any 4xx or 5xx code should be treated as a failure and logged for investigation.

ParametersJSON Schema
NameRequiredDescriptionDefault
request_bodyYesComplete SendGrid v3 payload. Pass entire JSON as request_body. The from field must always be lntcs@lntecc.com. Content-Type: application/json. Template/example: {

Tool Definition Quality

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It covers the asynchronous nature (HTTP 202 Accepted), error conditions (400, 401, 403, 429, 5xx), required headers, and the specific sender email requirement ('from field must always be lntcs@lntecc.com'). It could be more explicit about idempotency or side effects, but overall it's quite transparent.

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 well-structured with clear sections (use cases, important notes, headers, request body, response, error handling, rules). It is front-loaded with the core purpose. Although it is lengthy, every section serves a purpose given the complexity of the API. A slight reduction in verbosity could improve conciseness, but it remains efficient.

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 there is no output schema, the description fully explains the expected response (202 Accepted with empty body), lists all relevant error codes, and details the payload structure. It also addresses the sender email restriction and provides example use cases. This ensures the agent understands the tool's complete behavior without relying on additional documentation.

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

Parameters5/5

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

The input schema has a single parameter 'request_body' with a minimal description. The tool description compensates fully by detailing the nested structure (personalizations, from, content, etc.), response fields, and error handling. This adds significant meaning beyond the schema, making it highly useful for crafting correct invocations.

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 clearly states 'Sends an email to specified recipients using SendGrid's email delivery service.' This specific verb and resource combination distinguishes it from sibling tools like 'how_to_send_lnt_email' and 'lnt_email_brand_guidelines', which are guides rather than direct execution tools.

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 provides explicit use case triggers such as 'send an email', 'notify user by email', etc. It also includes important prerequisites like sender authorization and template variable verification. While it doesn't explicitly state when not to use it, the sibling tools are clearly distinct (guides vs. actual sending), making usage context clear.

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

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment
Try in Browser

Your Connectors

Sign in to create a connector for this server.

Resources