Entogo (Canada) transformers, switchgear, BESS, EV charging: catalogue, lead times, EV sizing, RFQ
Scored across 7 tools
Most tools have distinct targets: listing vs. product detail vs. lead time vs. quote handoff vs. capacity calculator. The main overlap is search_knowledge, which semantically indexes product, certification, lead-time and warranty content that get_product, get_lead_time and get_company_facts also serve directly, so an agent may occasionally choose the generic search where a specific getter would be better.
All seven names follow a clean snake_case verb_noun pattern (list_products, get_product, get_lead_time, get_company_facts, search_knowledge, request_quote_handoff, estimate_ev_charging_capacity). Verbs are distinct and descriptive with no style mixing.
Seven tools is well-scoped for a catalogue-plus-knowledge server: two discovery tools, three specific getters, one handoff, one calculator. Each tool earns its place and none appears redundant.
The surface covers discovery, product detail, company facts, lead time, quote routing and a domain calculator, which supports typical pre-sales workflows. Minor gaps: no dedicated tool for certifications, categories/solutions browsing, or comparing products, though search_knowledge and list_products partly compensate.
Runs the same engine as https://entogo.ca/tools/ev-charging-service-capacity-calculator/: code load (NEC 2023 / NEC 2026 / CEC 2024 Section 86) for a set of Level 2 and DC fast chargers, EMS-managed load when an energy management system is declared, planning-basis load with site diversity, recommended transformer kVA and service / switchboard rating, and a GREEN / YELLOW / RED verdict against an existing service when one is given. Planning estimate only.
| Name | Required | Description | Default |
|---|---|---|---|
| ems | No | ||
| code | No | Governing code edition | NEC_2023 |
| chargers | Yes | ||
| siteType | No | workplace | |
| servicePhase | No | ||
| serviceVoltage | No | Service line-to-line voltage, e.g. 208, 480, 600 | |
| existingService | No | Give the existing service to get a GREEN / YELLOW / RED verdict |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds useful behavioral context beyond the annotation: it runs the same engine as an external calculator, produces a verdict only when an existing service is provided, and handles EMS-managed load only when an EMS is declared.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-packed sentence that puts the core purpose first and then enumerates outputs in a scannable list. It is dense but not bloated; every clause adds information, though splitting it into short sentences or bullets would improve readability slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description usefully enumerates the main computed results and the conditional verdict behavior. It also communicates the planning-only scope. It does not spell out required inputs, but the schema already covers those, so the description is sufficient for a competent agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description must compensate, and it partially does by explaining the role of code editions, EMS, chargers, and existingService. However, it does not clarify less obvious parameters such as siteType, servicePhase, serviceVoltage, or charger sub-fields like dcfcBasis and ratingKw beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an EV-charging service capacity estimator powered by a specific engine, and lists its concrete outputs: code load, EMS-managed load, planning-basis load, transformer kVA, service rating, and a GREEN/YELLOW/RED verdict. It is clearly distinct from sibling tools like get_product or search_knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: for planning estimates of EV-charging service capacity under specific code editions. The phrase 'Planning estimate only' acts as an exclusion against using it for final engineering designs, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified company facts: legal name, founding, headquarters, contacts and office hours, factory and capacity narrative, lead-time and warranty commitments, certifications, standards position, quote channel and key URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be a safe read. The description adds meaningful content context ('verified company facts' plus categories), but does not disclose behavioral details such as whether the data is static, whether all facts are returned in one call, or how the response is structured. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, dense sentence that front-loads the key phrase 'Verified company facts' and then delivers a comma-separated enumeration of all content categories. Every item earns its place; no filler words or redundant explanations appear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description gives a thorough inventory of what the agent can expect to find, enabling correct selection for questions about company facts. The only notable gap is lack of clarification on the boundary with get_lead_time, but overall the tool is well-specified for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the description has no parameter burden. The description helpfully lists the output content areas, which substitutes for absent output schema detail. Baseline for zero-parameter tools is 4, and no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource ('Verified company facts') and enumerates a specific scope: legal name, founding, headquarters, contacts, office hours, factory/capacity narrative, lead-time/warranty commitments, certifications, standards, quote channel, and URLs. This makes its purpose distinct from the sibling tools, which target products, lead times, and quote handoff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description strongly implies use when a user needs company-level facts, by listing the exact categories it covers. However, it does not explicitly state when to use this tool vs. alternatives such as get_lead_time, which may overlap with the 'lead-time commitments' item. No direct routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delivery lead-time band for a product (weeks, purchase order to shipment) plus Entogo's company-wide lead-time and warranty commitments. Bands: catalogue EV chargers 4–8, medium manufactured equipment 16–24, large engineered-to-order systems 16–24 weeks; new cULus / CSA certification can extend a band, to within 36 weeks when the order needs it. IEC/CE equipment built for export markets: about 12 weeks.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product id / URL slug | |
| market | No | Buyer market: north-america = ANSI/IEEE (UL/CSA on request) build; eu = IEC/EN CE edition (Poland, Romania, EU); gcc = IEC Gulf edition; central-asia-caucasus = IEC, GOST-compatible edition (KZ UZ KG TJ TM AZ AM GE; never Russia / Belarus) | north-america |
Full record for one product by catalogue id (slug): specifications, features, applications, FAQs, certifications listed on the page, lead-time band, language editions, Markdown twin and the quote channel.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product id / URL slug, e.g. metal-clad-switchgear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, and the description adds meaningful behavioral context by enumerating the exact fields returned in the full record. This is valuable because there is no output schema to communicate return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One well-structured sentence that leads with the core action and scope, then enumerates the return contents in a compact list. No filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup with no output schema, the description fully substitutes for return-value documentation by listing the record's major sections. The tool is simple enough that the description leaves no critical gap for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the id parameter described as 'Product id / URL slug'. The description's 'by catalogue id (slug)' matches and reinforces, but does not add new parameter details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a full record for one product using its catalogue id/slug, with an explicit list of returned content. This distinguishes it sharply from siblings like list_products or search_knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clear: retrieve a complete product record when you have a specific product id/slug. It does not explicitly name alternative tools or when-not-to-use conditions, but the intended context is evident from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products in the catalogue, optionally filtered by category (power = transformers & substations; distribution = switchgear & distribution; storage = battery energy storage; emobility = EV charging & PV-storage-charging) and/or a keyword. Returns compact rows; call get_product for full specifications.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Case-insensitive match on title / model / summary, including the Polish, Romanian and Arabic edition titles | |
| category | No |
Returns the right channel for a request for quotation (RFQ): the transformer configurator deep link (pre-filled with the product name), the contact page, e-mail and phone numbers, office hours and the one-business-day response commitment. This tool stores nothing and sends nothing — the user completes the request on entogo.ca or by e-mail.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | Product name or id the user is interested in | |
| summary | No | One-paragraph project summary to paste into the form | |
| language | No | Language of the buyer — links point to that language edition of the site | en |
Semantic search over Entogo's product, solution, manufacturing, certification, lead-time and warranty knowledge (the same index that grounds the Ensight assistant). Returns the best-matching passages with source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | Number of passages to return | |
| query | Yes | Natural-language question or keywords |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to cover mutation or open-world assumptions. It adds useful context about the underlying index and output format, but it does not disclose potential behavioral nuances such as relevance ranking caveats or empty-result behavior. There is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the action and scope, uses a parenthetical to add valuable context about the Ensight index, and ends with the return type. Every phrase 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with fully documented parameters and no output schema, the description sufficiently covers what it searches, where it searches, and what it returns. It stops short of describing ordering or relevance semantics in detail, but 'best-matching' implies relevance-based ranking, and the schema covers the remaining invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies: the schema already documents the query as a natural-language question or keywords and topK as the number of passages to return. The description adds no parameter-level detail beyond this, though it is consistent with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('semantic search') and a precise scope: Entogo's product, solution, manufacturing, certification, lead-time, and warranty knowledge. It also distinguishes itself from structured lookup siblings like get_product or get_lead_time by framing the tool as passage-level, natural-language search, and it states the return type (best-matching passages with source URLs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it—for open-ended semantic questions across the named knowledge domains—and the schema reinforces this with a natural-language query field. However, it does not explicitly state when not to use it or point to alternatives like get_product for exact product lookups or get_lead_time for specific lead-time figures, so the decision rule is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_lead_time2 fields changedInput schema / properties / market / descriptionPrevious value: -"Buyer market: north-america = ANSI/IEEE (UL/CSA on request) build; eu = IEC/EN CE edition (Poland, Romania, EU); gcc = IEC Gulf edition"New value: +"Buyer market: north-america = ANSI/IEEE (UL/CSA on request) build; eu = IEC/EN CE edition (Poland, Romania, EU); gcc = IEC Gulf edition; central-asia-caucasus = IEC, GOST-compatible edition (KZ UZ KG TJ TM AZ AM GE; never Russia / Belarus)"Input schema / properties / market / enumPrevious value: -[
- "north-america",
- "eu",
- "gcc"
-]New value: +[
+ "north-america",
+ "eu",
+ "gcc",
+ "central-asia-caucasus"
+]request_quote_handoff1 field changedInput schema / properties / language / enumPrevious value: -[
- "en",
- "fr",
- "es",
- "ar",
- "pl",
- "ro"
-]New value: +[
+ "en",
+ "fr",
+ "es",
+ "ar",
+ "pl",
+ "ro",
+ "ru"
+]get_lead_time1 field changedInput schema / properties / marketAdded value: +{
+ "default": "north-america",
+ "description": "Buyer market: north-america = ANSI/IEEE (UL/CSA on request) build; eu = IEC/EN CE edition (Poland, Romania, EU); gcc = IEC Gulf edition",
+ "enum": [
+ "north-america",
+ "eu",
+ "gcc"
+ ],
+ "type": "string"
+}list_products1 field changedInput schema / properties / keyword / descriptionPrevious value: -"Case-insensitive match on title / model / summary"New value: +"Case-insensitive match on title / model / summary, including the Polish, Romanian and Arabic edition titles"request_quote_handoff1 field changedInput schema / properties / languageAdded value: +{
+ "default": "en",
+ "description": "Language of the buyer — links point to that language edition of the site",
+ "enum": [
+ "en",
+ "fr",
+ "es",
+ "ar",
+ "pl",
+ "ro"
+ ],
+ "type": "string"
+}estimate_ev_charging_capacityget_company_factsget_lead_timeget_productlist_productsrequest_quote_handoffsearch_knowledgeLead times, prices, tariffs and grid interconnection terms for factory and datacenter equipment.
EV-charging site analytics: utilization, demand, peak saturation and corridor benchmarks.
EV-charging site analytics: utilization, demand, peak saturation and corridor benchmarks.
Your building's energy in real time: smart-me meters, load profiles, EV charging, ZEV billing
Add one secure layer between your agents and this server.
