Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CordFind Generator Compatibility MCP Server What size generator cord do I need for 30 amps at 120V over 75 feet with 3% drop?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CordFind provides a public Model Context Protocol server for generator cord, plug, connector, and sizing research.
Run the public npm package from Claude Desktop, Cursor, VS Code, Codex, or another stdio MCP client:
{
"mcpServers": {
"cordfind": {
"command": "npx",
"args": ["-y", "cordfind-mcp"]
}
}
}The package is a small read-only stdio bridge to CordFind's canonical hosted MCP endpoint. No API key is required.
You can also run it directly:
npx -y cordfind-mcpUse the hosted Streamable HTTP endpoint:
{
"mcpServers": {
"cordfind": {
"url": "https://cordfind.com/api/mcp"
}
}
}Clients that only support local stdio servers can use mcp-remote:
{
"mcpServers": {
"cordfind": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://cordfind.com/api/mcp"]
}
}
}docker build -t cordfind-mcp .
docker run --rm -i cordfind-mcpThe server is public and does not require an API key. Read the full CordFind MCP documentation.
Related MCP server: datacenter-mcp-server
search_generator_guidesSearch CordFind generator guides by topic or question. Results include titles, descriptions, quick answers, and direct CordFind source URLs.
Inputs:
query — generator topic or question
limit — optional result limit from 1 to 10
get_connector_compatibilityScreen a generator receptacle, destination, and cord distance for direct compatibility, adapter needs, verification boundaries, or unsafe paths.
Inputs:
sourceConnectorId — l1430, l1420, l630, l530, 1450, cs50, tt30, or 520
targetId — inlet, rv, appliance, or distribution
distanceFeet — 25, 50, or 100
Use the human-facing generator cord finder to inspect the same workflow.
calculate_generator_cord_sizeCompare common American Wire Gauge sizes against planning ampacity and voltage-drop limits.
Inputs:
amps — 15, 20, 30, or 50
volts — 120 or 240
distanceFeet — one-way distance from 10 to 200 feet
dropLimitPercent — 3 or 5
Open the generator cord-size calculator for the interactive version and methodology.
The official MCP Registry manifest is available in server.json. It describes both the npm stdio package and the hosted Streamable HTTP endpoint. CordFind also publishes the manifest at:
https://cordfind.com/.well-known/mcp/server.jsonCordFind MCP responses are planning guidance, not approval for an electrical installation. Verify equipment labels, listings, ratings, and manufacturer instructions. Building wiring requires approved transfer equipment and qualified installation.
The manifest and documentation in this repository are licensed under the MIT License. CordFind site content and compatibility data remain subject to the terms published on CordFind.
Compare common American Wire Gauge sizes using load current, voltage, one-way distance, and a voltage-drop planning limit.
| Name | Required | Description | Default |
|---|---|---|---|
| amps | Yes | Planned current in amperes | |
| volts | Yes | Circuit voltage | |
| distanceFeet | Yes | One-way cord distance in feet | |
| dropLimitPercent | No | Planning voltage-drop limit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds no behavioral detail beyond its core purpose, such as calculation assumptions or output structure, but it does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action and resource, followed by the key inputs. It has no fluff, though it is somewhat minimal in detail.
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 the tool's moderate complexity and lack of output schema, the description is adequate but does not clarify expected results or edge cases. It also does not explicitly relate to sibling tools, leaving the agent to infer usage context from naming.
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 input schema provides 100% parameter coverage, including descriptions, allowed values for amps/volts/dropLimitPercent, and min/max for distanceFeet. The description merely restates the parameter categories without adding new meaning, so a baseline of 3 is appropriate.
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 states a specific verb ('Compare') and resource ('common American Wire Gauge sizes'), and lists the key input parameters. It is clearly distinct from sibling tools like search_generator_guides or get_connector_compatibility, though it does not specify the exact output format.
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 intended use is implied by the calculation-oriented description, but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The sibling tools have different purposes, but the description does not explicitly contrast them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a generator outlet, destination, and cord distance for direct compatibility, adapter needs, verification boundaries, or unsafe paths.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | Yes | Intended destination | |
| distanceFeet | Yes | Planned cord distance in feet | |
| sourceConnectorId | Yes | Generator receptacle family |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate the safe read-only, idempotent, non-destructive nature of the tool. The description adds context about what the screening returns (compatibility, adapter needs, verification boundaries, unsafe paths) but does not disclose further behavioral details such as output format or edge cases. It neither contradicts annotations nor substantially enriches them.
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, information-dense sentence that front-loads the primary action and lists the key output categories. It is concise without being vague, though the list of outcomes is a bit compressed and could be structured for even easier parsing.
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 the tool's simplicity (3 enum-constrained parameters, no output schema), the description sufficiently communicates the tool's purpose and expected result categories. It does not detail the exact return structure, but for a screening tool this level of completeness is adequate. The annotations cover the safety profile, so the overall context is complete.
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?
All three parameters have clear enumerations and schema descriptions with 100% coverage. The description does not add parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 the specific verb 'Screen' and clearly identifies the resource (generator outlet, destination, and cord distance) and the outcomes it produces (direct compatibility, adapter needs, verification boundaries, unsafe paths). This differentiates it from sibling tools like search_generator_guides and calculate_generator_cord_size, which focus on searching and numeric calculation respectively.
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 that this tool is for evaluating compatibility scenarios rather than searching guides or computing wire sizes, but it does not explicitly state when to use it over the alternatives, nor does it mention any exclusions or prerequisites. The intended use is discernible but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CordFind for generator cords, plugs, sizing, transfer equipment, maintenance, and safety guidance. Results include direct CordFind source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results | |
| query | Yes | Generator topic or question |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds that results include direct CordFind source URLs, which is useful, but it does not detail response shape, pagination, or error behavior. This modest addition is reasonable given 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The core search action and subject matter are front-loaded, and the result detail in the second sentence is directly useful to an agent. Every sentence earns its place.
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 read-only search tool with fully documented parameters and safety annotations, the description covers the essential behavioral context. It includes result behavior (direct source URLs), though it does not specify the full result structure since no output schema is provided. Slightly more detail on return format would make it fully complete.
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%, with both query and limit documented in the input schema. The description's topic list helps inform what to put in the query but does not add meaning beyond the schema. This aligns with the baseline for fully covered parameters.
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 a specific action ('Search CordFind') and a specific resource ('generator cords, plugs, sizing, transfer equipment, maintenance, and safety guidance'). It also notes that results include direct source URLs, which further clarifies the tool's purpose and distinguishes it from the more specialized sibling tools.
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 the tool by listing the topics it covers, but it does not explicitly mention when to avoid it or prefer a sibling like calculate_generator_cord_size or get_connector_compatibility. The usage context is present but the alternatives are not clearly routed.
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.
v1.1.0calculate_generator_cord_sizeget_connector_compatibilitysearch_generator_guidesScored across 3 tools
Each tool has a clearly distinct purpose: finding guidance content, screening connector compatibility, and calculating wire gauge. There is minimal overlap between searching for information and performing specific engineering calculations.
All three tools follow a consistent verb_noun snake_case pattern (search_generator_guides, get_connector_compatibility, calculate_generator_cord_size). The verbs match their actions and the objects clearly describe the target domain.
Three tools is well-scoped for the server's narrow purpose of generator cord guidance, compatibility, and sizing. Each tool addresses a distinct part of the workflow without redundancy or bloat.
The toolset covers the core workflow: learn (search guides), verify (compatibility screening), and calculate (wire sizing). Minor gaps exist, such as lacking a dedicated adapter lookup or detailed connector reference, but agents can work around these using the search tool.
Generate 12V/24V/48V wiring diagrams and size wires, fuses, batteries, solar, and inverters.
Licensed master electrician in SE Wisconsin — estimates, scheduling, and code lookups via AI.
Access and manage CenterPoint Connect data for property management, construction, and service oper…
Construction product lookup for Simpson Strong-Tie structural catalog
