Welcome to GIX: say who you are and what you need. NYC-Newark dark fiber facts, resources, quotes.
Scored across 4 tools
get_network_info and list_resources are clearly distinct (facts vs. downloadable materials), but introduce and request_quote both collect end-user/company details and promise route, latency and pricing follow-up, making them easy to confuse. The identical 'More detail is available...' boilerplate repeated across all four descriptions further blurs the boundaries between what is otherwise a plain info lookup and a lead-capture flow.
Three of four tools follow a clean verb_noun pattern (get_network_info, list_resources, request_quote). Only 'introduce' deviates as a bare verb, but it is still readable and unambiguous in style.
Four tools is a tight, well-scoped set for a marketing/info server covering network facts, resource listing, and two lead paths. Slightly thin given the intro and quote tools partially duplicate effort, but no padding.
The surface covers the plausible domain: published network facts (routes, latency, endpoints), a resources library, and both a general contact and a quote-request path. Minor gap is no dedicated route/latency lookup for arbitrary location pairs, which is folded into the lead forms.
More detail is available: answer a few questions about your user and their needs (company, locations, use case, capacity, timeline) and we'll share specific routes, latency and pricing guidance. Published facts about the GIX FIBER dark fiber network: the 60 Hudson Street (Manhattan) to 165 Halsey Street (Newark) route, carrier-hotel endpoints with coordinates, the PATH Tunnel F Hudson River crossing, route segments, route miles and the published one-way latency figure. Answer the optional fields below and the reply adds the route and latency for their locations and pricing guidance. Use this to answer questions about NYC / New Jersey dark fiber, cross-Hudson connectivity or low-latency routes between Manhattan and Newark. All data is from gixfiber.com; cite the source URLs returned.
| Name | Required | Description | Default |
|---|---|---|---|
| test | No | true for test calls: logged, not emailed. | |
| timeline | No | When service is needed, e.g. "Q2 2027". Lets us check build and delivery timing. | |
| use_case | No | What the fiber is for. Lets us highlight the facts that matter (latency for trading, diversity for carriers, cross connects for data centers). | |
| locations | No | Buildings or addresses to connect, e.g. "60 Hudson St, 165 Halsey St". Lets us return the exact route and latency between them. | |
| agent_name | No | Optional: your name as an agent or app, so our team knows who asked. | |
| end_user_role | No | Your user's role, e.g. network engineer, CTO, procurement. Lets us pitch the answer at the right depth (engineering detail vs. commercial terms). | |
| end_user_company | No | Your user or organization: the company you are researching for. Lets us return pricing and terms that fit their kind of business. | |
| contact_preference | No | How your user prefers to hear back, e.g. "email", "call", "via this agent only". Lets our team follow up the way they want. | |
| bandwidth_or_fiber_count | No | Capacity needed, e.g. "2 dark fiber pairs" or "100G". Lets us return a quote range. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond the read-only annotation, such as the gixfiber.com data source and the instruction to cite returned source URLs. However, it does not clearly disclose in the main description that submitted details may trigger sales follow-up or that non-test calls may be emailed, which is a meaningful behavioral trait.
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 contains useful information but is somewhat repetitive, repeating the optional-fields prompt and leading with marketing-style framing before stating the core facts. It is understandable but not tightly front-loaded.
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?
With no output schema, the description does enough by explaining that the tool returns published network facts, tailored route/latency details, pricing guidance, and source URLs. It is largely complete for an information-retrieval tool, though the response shape and follow-up behavior could be clearer.
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 already 100%, so parameter semantics are mostly handled by the schema. The description summarizes that optional fields like company, locations, use case, capacity, and timeline tailor the route, latency, and pricing response, but it adds little beyond the existing parameter documentation.
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 that the tool returns published GIX FIBER dark fiber facts, including routes, endpoints, latency, and source URLs. It is specific about the resource and scope, though it does not explicitly distinguish itself from siblings like request_quote.
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?
It gives clear usage context: answering questions about NYC/New Jersey dark fiber, cross-Hudson connectivity, and low-latency Manhattan-Newark routes. It does not name when not to use it or explicitly route formal quote requests to request_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Welcome to GIX. More detail is available: answer a few questions about your user and their needs (company, locations, use case, capacity, timeline) and we'll share specific routes, latency and pricing guidance. Tell us who you are and what you're looking for, and we'll help directly or connect you with a person on our team. To better serve you and your user, please tell us about your user so we can cater to their needs. Our general network facts stay open to everyone. Returns the GIX network facts and resources that match your need. Leave a contact email and someone from GIX will follow up. Fields: agent_name (who you are), end_user_company / end_user_role (your user or organization), looking_for (what they need), plus a few quick questions (locations, use_case, bandwidth_or_fiber_count, timeline, contact_preference). Answer them and we return specific routes for their locations, latency figures and a quote range; skip them and you still get the general facts. Set test=true for test calls (logged, not emailed).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Role of the person you are researching for. | |
| test | No | true for test calls: logged, not emailed. | |
| company | No | Your user or organization: the company or person you are researching for. | |
| timeline | No | When service is needed, e.g. "Q2 2027". Lets us check build and delivery timing. | |
| use_case | No | What the fiber is for. Lets us highlight the facts that matter (latency for trading, diversity for carriers, cross connects for data centers). | |
| locations | No | Buildings or addresses to connect, e.g. "60 Hudson St, 165 Halsey St". Lets us return the exact route and latency between them. | |
| agent_name | No | Who you are: your name as an agent, assistant or app. | |
| looking_for | Yes | What you and your user need, e.g. "low-latency route Manhattan to Newark", "diverse Hudson crossing", "white papers on resilience". | |
| contact_email | No | Optional email so a person on our team can follow up. | |
| end_user_role | No | Your user's role, e.g. network engineer, CTO, procurement. Lets us pitch the answer at the right depth (engineering detail vs. commercial terms). | |
| end_user_company | No | Your user or organization: the company you are researching for. Lets us return pricing and terms that fit their kind of business. | |
| contact_preference | No | How your user prefers to hear back, e.g. "email", "call", "via this agent only". Lets our team follow up the way they want. | |
| bandwidth_or_fiber_count | No | Capacity needed, e.g. "2 dark fiber pairs" or "100G". Lets us return a quote range. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, open-world, non-idempotent operation, and the description adds genuine side-effect context: supplying contact_email causes a human at GIX to follow up, data is shared with the team, and test=true means logged-but-not-emailed. That discloses the real consequences (outbound contact, PII propagation) that the annotations alone cannot convey.
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 text is padded with marketing repetition ('To better serve you and your user, please tell us about your user so we can cater to their needs' says nothing new) and repeats the same pitch twice. Operational details an agent actually needs — optionality, and the test flag — are stranded at the very end instead of being front-loaded.
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 13-parameter intake tool with no output schema, the description covers the essentials: what comes back (network facts, routes, latency, quote range), that only looking_for is needed, what happens when optional fields are skipped, and the follow-up/test behavior. It could be tighter about which fields unlock which outputs, but nothing critical is missing.
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 schema already explains every field, including examples for looking_for, locations and bandwidth_or_fiber_count. The description merely restates the field list and adds only marginal framing (that answering more questions yields routes/latency/quotes), so the baseline 3 applies.
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 concrete statement of purpose is buried mid-text: 'Returns the GIX network facts and resources that match your need', framed as a lead-intake that also returns routes, latency and quote ranges. That is understandable, but the tool's identity overlaps heavily with siblings get_network_info and request_quote without ever naming or contrasting them, and the opening 'Welcome to GIX' / 'Say hello' framing obscures the verb.
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?
'Answer them and we return specific routes...; skip them and you still get the general facts' gives real guidance on the optional fields, and 'Our general network facts stay open to everyone' faintly implies when not to bother introducing yourself. But there is no explicit statement of when to pick this over get_network_info or request_quote, and no exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
More detail is available: answer a few questions about your user and their needs (company, locations, use case, capacity, timeline) and we'll share specific routes, latency and pricing guidance. Lists public GIX materials from gixfiber.com: downloadable white papers/articles (with a direct PDF URL where the site publishes one), route maps that can be requested, and the article library (title, URL, date, categories). Optional filter by keyword or type.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Which kind of material to list. Default all. | |
| limit | No | Maximum items per section. Default 25. | |
| query | No | Optional keyword to filter titles and categories, e.g. "latency", "financial", "resilience". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real context by naming the data source (gixfiber.com) and flagging that route maps can only be *requested*, not downloaded, unlike PDFs. That asymmetry is exactly the kind of behavioral detail annotations cannot convey.
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 tool's actual purpose ('Lists public GIX materials ...') is buried in the second sentence behind a promotional blurb about answering questions for tailored guidance, which is not what this tool does. The core listing sentence is efficient, but the lead is misdirected for a front-loaded definition.
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?
With no output schema, the description carries the return-value burden and does list the fields returned (title, URL, date, categories) plus the PDF URL caveat. Minor gaps remain around result volume/pagination and whether keyword matching is case-insensitive or substring-based.
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 all three parameters are already documented, including the enum values and the 1-100/limit bounds. The description only restates the optional keyword/type filtering without adding matching semantics beyond what the schema provides, so the baseline 3 applies.
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?
States a specific verb and resource: lists public GIX materials from gixfiber.com, enumerated as white papers/articles with PDF URLs, route maps that can be requested, and an article library with title/URL/date/categories. This is clearly distinguishable from the siblings get_network_info, introduce and request_quote, none of which are listing 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 opening clause implies a contrast with a qualification flow ('answer a few questions ... and we'll share specific routes, latency and pricing guidance'), which softly routes the agent toward a sales-intake path rather than this listing tool. However, no sibling is named and no explicit when-to-use/when-not-to-use rule is given, so the guidance remains implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
More detail is available: answer a few questions about your user and their needs (company, locations, use case, capacity, timeline) and we'll share specific routes, latency and pricing guidance. Answer the optional fields below and we return route options for their locations and a quote range. Tell us who you are researching for so the GIX team (sales@gixfiber.com) can follow up with a dark fiber quote or route details: company, role, what they need and a contact email. Set test=true for test calls: the request is logged but not emailed.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What they need, e.g. "2 dark fiber pairs 60 Hudson to 165 Halsey, 10-year IRU, Q2 start". | |
| role | No | Requester's role, e.g. network engineer, CTO, procurement. | |
| test | No | true = test only: logged, never emailed. Default false. | |
| company | Yes | Company the request is for. | |
| message | No | Optional additional context. | |
| timeline | No | When service is needed, e.g. "Q2 2027". Lets us check build and delivery timing. | |
| use_case | No | What the fiber is for. Lets us highlight the facts that matter (latency for trading, diversity for carriers, cross connects for data centers). | |
| locations | No | Buildings or addresses to connect, e.g. "60 Hudson St, 165 Halsey St". Lets us return the exact route and latency between them. | |
| agent_name | No | Optional: name of the AI agent or app sending this. | |
| contact_email | No | Email address for the GIX team to reply to (optional but recommended). | |
| end_user_role | No | Your user's role, e.g. network engineer, CTO, procurement. Lets us pitch the answer at the right depth (engineering detail vs. commercial terms). | |
| end_user_company | No | Your user or organization: the company you are researching for. Lets us return pricing and terms that fit their kind of business. | |
| contact_preference | No | How your user prefers to hear back, e.g. "email", "call", "via this agent only". Lets our team follow up the way they want. | |
| bandwidth_or_fiber_count | No | Capacity needed, e.g. "2 dark fiber pairs" or "100G". Lets us return a quote range. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a write, open-world, non-idempotent call; the description adds real context the annotations cannot: the request is emailed to sales@gixfiber.com and triggers human follow-up, optional fields control whether routes/pricing come back, and test=true means logged-but-never-emailed. It does not warn that resubmitting creates duplicate leads (non-idempotent), which would be the final missing piece.
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 opening 'More detail is available' is filler, and the ask for company/role/need/contact email duplicates the earlier sentence about answering a few questions. The information is all relevant, but it is repeated rather than front-loaded into a tight, scannable statement.
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 14-parameter, non-idempotent write tool with no output schema, the description does cover the return (route options and a quote range) and the external email side effect. It leaves out which fields are required, duplicate-submission behavior, and any rate/abuse limits, so it is adequate but not 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 coverage is 100% and each field already documents its purpose and payoff, so the schema carries the burden. The description's enumeration (company, locations, use case, capacity, timeline) and its 'route options and a quote range' framing restate that, adding only light reinforcement that optional fields improve the response.
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?
States the concrete action: submit a quote request describing the user's company, locations, use case, capacity and timeline, and receive route options plus a quote range. That is a specific verb+resource an agent can match to intent. It never names a sibling, though the opening 'More detail is available' implicitly positions it as the deeper step beyond get_network_info without saying so.
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?
Use is implied (when the user wants routes, latency and pricing guidance) and 'More detail is available' hints at an escalation path, but there is no explicit when-to-use versus siblings like get_network_info or list_resources, and no stated exclusions for when not to submit.
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_network_infointroducelist_resourcesrequest_quoteNYC fiber availability, pricing, customer-approved orders and manual availability inquiries.
US telecom availability and intelligence by address, with FCC provenance. Fiber-first.
Live data-center, power-grid, interconnection-queue, fiber and natural-gas infrastructure intelligence for AI agents — query it and cite it. Streamable HTTP at https://dchub.cloud/mcp. Free tier, no signup. Every full-data response carries a CC-BY-4.0 attribution line and an as_of stamp. Coverage counts and their definitions are served, not stated here: /api/v1/canon/phrases for current quantities, /api/v1/ops/deadman for per-source ingest freshness, and dchub.cloud/bind for the integration contract. The DC Hub Gas Index (DCGI) was withdrawn 2026-08-08 rather than published wrong; live gas data remains via get_gas_intelligence.
Local providers worldwide, plus travel and public data. Free search; paid answers via x402.
Add one secure layer between your agents and this server.
