Skip to main content
Glama

GIX FIBER dark fiber (NYC / NJ)

Say hello to GIX

introduce

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 show how the GIX route fits their locations and use case, and pass a quote request to our team. 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 tell you how their locations connect to the GIX route and which published facts matter for their use case, and our team can follow up with a quote; skip them and you still get the general facts. Set test=true for test calls (logged, not emailed).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "looking_for": "<looking_for>"
    },
    "name": "introduce"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleNoRole of the person you are researching for.
testNotrue for test calls: logged, not emailed.
companyNoYour user or organization: the company or person you are researching for.
timelineNoWhen service is needed, e.g. "Q2 2027". Helps our team check delivery timing.
use_caseNoWhat the fiber is for. Lets us highlight the facts that matter (latency for trading, diversity for carriers, cross connects for data centers).
locationsNoBuildings or addresses to connect, e.g. "60 Hudson St, 165 Halsey St". Lets us say how they connect to the GIX route (60 Hudson St to 165 Halsey St).
agent_nameNoWho you are: your name as an agent, assistant or app.
looking_forYesWhat you and your user need, e.g. "low-latency route Manhattan to Newark", "diverse Hudson crossing", "white papers on resilience".
contact_emailNoOptional email so a person on our team can follow up.
end_user_roleNoYour user's role, e.g. network engineer, CTO, procurement. Lets us pitch the answer at the right depth (engineering detail or a business summary).
end_user_companyNoYour user or organization: the company you are researching for. Helps our team prepare a quote that fits their kind of business.
contact_preferenceNoHow 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_countNoCapacity needed, e.g. "2 dark fiber pairs" or "100G". Helps our team prepare a quote.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / end_user_company / description
      Previous value: -"Your user or organization: the company you are researching for. Lets us return pricing and terms that fit their kind of business."New value: +"Your user or organization: the company you are researching for. Helps our team prepare a quote that fits their kind of business."
    • changedInput schema / properties / end_user_role / description
      Previous value: -"Your user's role, e.g. network engineer, CTO, procurement. Lets us pitch the answer at the right depth (engineering detail vs. commercial terms)."New value: +"Your user's role, e.g. network engineer, CTO, procurement. Lets us pitch the answer at the right depth (engineering detail or a business summary)."
    • changedInput schema / properties / locations / description
      Previous value: -"Buildings or addresses to connect, e.g. \"60 Hudson St, 165 Halsey St\". Lets us return the exact route and latency between them."New value: +"Buildings or addresses to connect, e.g. \"60 Hudson St, 165 Halsey St\". Lets us say how they connect to the GIX route (60 Hudson St to 165 Halsey St)."
    • changedInput schema / properties / timeline / description
      Previous value: -"When service is needed, e.g. \"Q2 2027\". Lets us check build and delivery timing."New value: +"When service is needed, e.g. \"Q2 2027\". Helps our team check delivery timing."
  2. Changed1 schema field changed
    • changedInput schema / properties / bandwidth_or_fiber_count / description
      Previous value: -"Capacity needed, e.g. \"2 dark fiber pairs\" or \"100G\". Lets us return a quote range."New value: +"Capacity needed, e.g. \"2 dark fiber pairs\" or \"100G\". Helps our team prepare a quote."
  3. First observed

TDQS

C2.9/5.0
Behavior4/5

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

The description adds meaningful behavior beyond annotations: contact details may trigger human follow-up, quote requests are passed to the team, and test=true calls are logged but not emailed. It does not fully explain data handling or rate limits, but it discloses the key side effects an agent needs to know.

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 a long, repetitive paragraph with several restatements of the same intake idea. The useful purpose is buried behind welcomes and repeated follow-up language, making it harder to scan for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It covers the 13 parameters at a high level and notes optional quick questions, test behavior, and follow-up. However, with no output schema it gives only a vague sense of the return value and does not clearly differentiate the tool from its siblings.

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

Parameters3/5

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

Schema description coverage is 100%, so parameter semantics are already well documented. The description adds grouping and workflow context, including that quick questions are optional, but mostly repeats field meanings rather than adding syntax or constraints beyond the schema.

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

Purpose3/5

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

The description says the tool returns matching GIX network facts/resources and can pass a quote request, so the broad purpose is inferable. However, it uses many overlapping actions and never distinguishes itself from siblings like get_network_info, list_resources, or request_quote, leaving the core identity somewhat muddled.

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?

It implies usage by suggesting users answer questions for personalized results or skip them for general facts, but it gives no explicit when-to-use guidance against alternatives. An agent is left to infer whether to call this versus get_network_info, list_resources, or request_quote.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources