contact_trading_deskThe human channel. The GSC Trading Desk is informed by Navigator across all GSC agentic assets — a human reads, a human answers. Use it for anything a person should decide; agents use Instant Messaging.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It reveals that a human intervenes (slower, async) and that the tool is a communication channel, not a data-fetching endpoint. It doesn't disclose turnaround expectations, escalation paths, or whether replies arrive via the same channel, but the core behavioral trait (human-mediated) 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse sentences, front-loaded with the core 'human channel' identity. Minimal waste; the key usage guidance is in the final sentence. Slightly more verbose than strictly needed but acceptable.
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 zero-parameter, no-output-schema tool, the description is sufficient. It tells the agent this is the human fallback, gives the trigger condition, and rules out agents. Nothing else an agent needs to invoke it is missing — though it could note that responses are asynchronous.
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 schema has zero parameters. The description essentially communicates that no structured input is needed — the agent simply sends its message. This is important context that the schema alone (empty properties) doesn't fully convey, so the description adds meaningful functional meaning.
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 this is 'The human channel' for the GSC Trading Desk, explaining that a human reads and answers. It distinguishes this from agent-to-agent communication, though it doesn't explicitly name the sibling tool it contrasts with ('agents use Instant Messaging' implies instant_message_agents).
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?
Explicitly states 'Use it for anything a person should decide; agents use Instant Messaging.' This provides clear when-to-use guidance and points to the alternative channel (Instant Messaging for agents), though it doesn't elaborate on edge cases or when a human decision is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct outcome: search, verify, identifier policy, graph overview, market operators, standards, payment-rail context, and human/agent escalation. Even the closely related search_brands → get_brand → get_brand_identifiers path is explicitly staged as a workflow, and contact_trading_desk vs instant_message_agents is delimited by audience.
Tool names follow a predictable lowercase snake_case pattern: mostly get_<resource>, with action verbs search_, contact_, and instant_message_ for the non-read operations. The naming style is consistent throughout, and the less conventional instant_message_agents is still recognizable as verb-plus-object.
Eleven tools fits the ideal 3–15 range for a coherent agent-facing service. Each tool covers an identifiable slice of the domain—discovery, verification, identifiers, market context, standards, messaging, or settlement context—and none feel redundant.
The core sourcing workflow is covered: FOUND via search, VERIFIED via get_brand, ANSWERABLE via get_brand_identifiers, then human/agent follow-up. The main gaps are the referenced resolve_gtin/resolve_sparks/check_eligibility tools and any purchase/pricing/order-writing surface, but those appear intentionally externalized through doors and transaction MCP.