FCC copper retirement lookups and a broker-reviewed IT advisor. No supplier names, no prices.
Scored across 3 tools
Each tool targets a clearly distinct action: consulting an AI advisor, looking up a deterministic dataset, and requesting a human callback. The descriptions explicitly differentiate the conversational advisor from the consent-gated broker callback, so an agent can easily choose the right tool.
All three names follow a consistent snake_case verb+object pattern: ask_sync_advisor, check_copper_retirement, request_broker_callback. The verbs are distinct but the structural convention is uniform and predictable.
Three tools are well-scoped for this focused advisory and data-lookup service. Each tool earns its place by covering a core workflow step (consult, check, escalate), with no redundant or extraneous operations.
The surface covers the main lifecycle: initiate an advisor session, retrieve copper retirement status, and request human follow-up. Minor gaps exist—such as no direct tool to query the status of a pending human review or to retrieve a claim_url without going through the advisor—but these are arguably external steps.
Consult CHNLSYNC's advisor about the user's IT environment.
First call: omit session_id/session_token and provide company_name plus pain (a plain-language description of what is not working) — a private advisor workspace is created and its credentials are returned. Later calls: pass session_id, session_token AND conversation_id back to continue the same conversation. Persist all three privately across turns. Incomplete continuation handles are rejected before any write; recover the previous tool result instead of creating another workspace. Never automatically retry a failed write: it may already have been recorded. Replies never contain supplier names or pricing — those come only after a human broker review, via the claim_url or a requested callback.
| Name | Required | Description | Default |
|---|---|---|---|
| pain | No | What is not working; required for a new workspace. | |
| message | Yes | The user's technology question; no secrets. | |
| session_id | No | Returned workspace ID; required for continuation. | |
| company_name | No | Company name; required for a new workspace. | |
| session_token | No | Returned private token; required with session_id. | |
| conversation_id | No | Returned conversation ID; required for follow-up turns. |
| Name | Required | Description |
|---|---|---|
| claim_url | Yes | Private claim link; share only with the workspace owner. |
| disclosure | Yes | Human review precedes supplier and pricing disclosure. |
| session_id | Yes | Workspace handle to retain with conversation_id. |
| missing_info | No | Initial information gaps. |
| review_status | Yes | Current human-review status, when available. |
| session_token | Yes | Private credential; retain, never publish. |
| conversation_id | Yes | Pass back with both session credentials next turn. |
| assistant_message | Yes | Buyer-safe advisor response. |
| environment_summary | No | Initial workspace summary. |
| follow_up_questions | Yes | Questions that clarify the user's needs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag a non-read-only, non-idempotent, non-destructive write, and the description adds genuinely new behavioral context: a workspace is created and its credentials returned, incomplete continuation handles are rejected before any write, and failed writes must not be retried because they may already have been recorded. The only real gap is that it does not describe the shape or latency of advisor replies, but the output schema exists to cover that.
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 purpose is front-loaded in sentence one and every subsequent sentence carries operational weight (first call, continuation, retry, disclosure limits). It is dense rather than padded, though the credential-persistence and rejection sentences could be tightened 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?
For a stateful, credential-bearing multi-turn tool with annotations and an output schema, the description covers the full lifecycle: workspace creation, handle persistence, continuation, failure handling, and the limits of what replies contain. Nothing an agent needs in order to call it correctly across turns appears to be 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 baseline is 3, but the description adds conditional semantics the schema cannot express: which parameter combination is required per call phase and the instruction to persist all three handles privately across turns. It stops short of explaining the UUID/token formats, which the schema patterns already handle.
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 first sentence gives a specific verb and resource (consult CHNLSYNC's advisor about the user's IT environment), and the closing paragraph draws the boundary with the sibling broker flow by stating that supplier names and pricing only arrive after human broker review via claim_url or a requested callback. An agent can tell what this tool is and where it stops without opening the schema.
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 explicitly separates the first call (omit session_id/session_token, supply company_name plus pain) from continuation calls (session_id, session_token AND conversation_id), and adds recovery guidance (reuse the previous tool result rather than creating another workspace) plus a no-auto-retry rule. Nothing about when to use it or how to sequence turns 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.
Look up US copper/POTS retirement program status by carrier and state.
Deterministic read of CHNLSYNC's FCC-sourced dataset (CC BY 4.0 — cite
the returned source_url). carrier accepts display names like "AT&T",
"Lumen", "Frontier"; state is a two-letter abbreviation. Omit both
for the full dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter US state, e.g. TX. | |
| carrier | No | Carrier display name, e.g. AT&T. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | As-of date of static records, not of latest_filings. |
| source | Yes | Source methodology and limitations. |
| license | Yes | Reuse license; attribution is required. |
| records | Yes | Carrier/state entries matching the filters. |
| source_url | Yes | Attribution URL for the published dataset. |
| latest_filings | Yes | Up to 20 reviewed matching filings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: deterministic output, FCC-sourced derivation, CC BY 4.0 licensing, and the requirement to cite the returned source_url.
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?
Front-loaded with the core purpose, then the data provenance, then parameter guidance. Efficient overall, though the licensing/citation sentence is somewhat parenthetical and could be trimmed 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?
An output schema exists so return values need not be described, and the description still adds the source_url citation obligation that an agent would otherwise miss. For a two-optional-parameter read tool, nothing needed to call it correctly is absent.
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% and the schema already gives examples ('TX', 'AT&T'), so the baseline is 3. The description reinforces the display-name and two-letter abbreviation formats and the omit-both behavior, but adds little beyond what the schema 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?
States a specific verb (look up) plus resource (US copper/POTS retirement program status) and the two filtering dimensions. It is clearly distinguishable from the siblings ask_sync_advisor and request_broker_callback, which are unrelated functions.
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 tells the agent that omitting both parameters returns the full dataset, which is real when-to-use guidance. It does not name any alternative tool or state exclusions, but the siblings are unrelated so that omission costs little.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a CHNLSYNC human broker to contact the user about their case.
Only call this with the user's explicit consent to share their name and
email with CHNLSYNC. Requires the session credentials returned by
ask_sync_advisor. The result's book_url is an optional scheduling
link you may offer the user as a next step ("pick a time now"); the
callback is already queued and a broker will reach out either way, so
never present booking as required or as a confirmed appointment. Do not
automatically retry after a timeout: the request may already be recorded.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Workspace ID returned by the advisor. | |
| contact_name | Yes | Name the user consented to share. | |
| contact_email | Yes | Email the user explicitly consented to share. | |
| session_token | Yes | Private workspace credential. |
| Name | Required | Description |
|---|---|---|
| status | Yes | Callback request recorded, not yet completed. |
| book_url | Yes | Optional scheduling link; booking is not required. |
| disclosure | Yes | Human-review disclosure supplied by the backend. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, open-world behavior, and the description adds the reasons: the callback can be queued server-side so a retry may duplicate a recorded request, and the returned book_url is optional rather than a confirmation. This is exactly the kind of context 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?
Front-loaded with the core action, then layered constraints in descending priority. Every sentence carries a distinct obligation (consent, credentials, book_url framing, no-retry) with no 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 mutation tool with an output schema, the description covers what an agent still needs: consent prerequisite, credential source, non-idempotency handling, and how to interpret the returned book_url. Nothing material 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 all four parameters are documented structurally (session_id as workspace ID, contact_name/contact_email as consented values, session_token as private credential). The description reinforces the consent framing but adds no syntax or format detail beyond the schema, which is the baseline 3 case.
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: asking a CHNLSYNC human broker to contact the user about their case. It also positions itself relative to the sibling ask_sync_advisor by naming it as the source of the required session credentials, so the agent can tell the two apart.
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?
Gives explicit preconditions (user's explicit consent to share name and email; credentials from ask_sync_advisor), an explicit no-retry rule on timeout, and explicit presentation guidance for book_url ('never present booking as required or as a confirmed appointment'). When-to-use and when-not-to-act are both covered.
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.
ask_sync_advisor18 fields changedInput schema / properties / company_name / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 255,
+ "minLength": 1,
+ "pattern": "\\S",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / company_name / descriptionAdded value: +"Company name; required for a new workspace."Input schema / properties / conversation_idAdded value: +{
+ "anyOf": [
+ {
+ "pattern": "^[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Returned conversation ID; required for follow-up turns."
+}Input schema / properties / message / descriptionAdded value: +"The user's technology question; no secrets."Input schema / properties / message / maxLengthAdded value: +8000Input schema / properties / message / minLengthAdded value: +1Input schema / properties / message / patternAdded value: +"\\S"Input schema / properties / pain / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 4000,
+ "minLength": 1,
+ "pattern": "\\S",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / pain / descriptionAdded value: +"What is not working; required for a new workspace."Input schema / properties / session_id / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "pattern": "^[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / session_id / descriptionAdded value: +"Returned workspace ID; required for continuation."Input schema / properties / session_token / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 512,
+ "minLength": 1,
+ "pattern": "^\\S+$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / session_token / descriptionAdded value: +"Returned private token; required with session_id."Output schema / additionalPropertiesRemoved value: -trueOutput schema / descriptionAdded value: +"An advisor reply with the complete handle needed to continue safely."Output schema / propertiesAdded value: +{
+ "assistant_message": {
+ "description": "Buyer-safe advisor response.",
+ "title": "Assistant Message",
+ "type": "string"
+ },
+ "claim_url": {
+ "description": "Private claim link; share only with the workspace owner.",
+ "title": "Claim Url",
+ "type": "string"
+ },
+ "conversation_id": {
+ "description": "Pass back with both session credentials next turn.",
+ "format": "uuid",
+ "title": "Conversation Id",
+ "type": "string"
+ },
+ "disclosure": {
+ "description": "Human review precedes supplier and pricing disclosure.",
+ "title": "Disclosure",
+ "type": "string"
+ },
+ "environment_summary": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Initial workspace summary.",
+ "title": "Environment Summary"
+ },
+ "follow_up_questions": {
+ "description": "Questions that clarify the user's needs.",
+ "items": {
+ "type": "string"
+ },
+ "title": "Follow Up Questions",
+ "type": "array"
+ },
+ "missing_info": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Initial information gaps.",
+ "title": "Missing Info"
+ },
+ "review_status": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Current human-review status, when available.",
+ "title": "Review Status"
+ },
+ "session_id": {
+ "description": "Workspace handle to retain with conversation_id.",
+ "format": "uuid",
+ "title": "Session Id",
+ "type": "string"
+ },
+ "session_token": {
+ "description": "Private credential; retain, never publish.",
+ "minLength": 1,
+ "title": "Session Token",
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "assistant_message",
+ "follow_up_questions",
+ "conversation_id",
+ "review_status",
+ "claim_url",
+ "disclosure",
+ "session_id",
+ "session_token"
+]Output schema / titleAdded value: +"AdvisorResponse"check_copper_retirement10 fields changedInput schema / properties / carrier / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 255,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / carrier / descriptionAdded value: +"Carrier display name, e.g. AT&T."Input schema / properties / state / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "pattern": "^[A-Za-z]{2}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / state / descriptionAdded value: +"Two-letter US state, e.g. TX."Output schema / $defsAdded value: +{
+ "CopperFiling": {
+ "description": "One reviewed public filing with its own dates and primary-source link.",
+ "properties": {
+ "carrier": {
+ "description": "Carrier named by the filing.",
+ "title": "Carrier",
+ "type": "string"
+ },
+ "docket": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "FCC docket identifier, when available.",
+ "title": "Docket"
+ },
+ "filed_at": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Filing timestamp, when known.",
+ "title": "Filed At"
+ },
+ "filer": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Filing organization, when known.",
+ "title": "Filer"
+ },
+ "geography_detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Geographic scope from the source.",
+ "title": "Geography Detail"
+ },
+ "granted_at": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Grant timestamp, when known.",
+ "title": "Granted At"
+ },
+ "kind": {
+ "description": "Application, public notice, grant or carrier notice.",
+ "title": "Kind",
+ "type": "string"
+ },
+ "retirement_effective_at": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Effective date, when established.",
+ "title": "Retirement Effective At"
+ },
+ "source_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Primary-source filing URL, when available.",
+ "title": "Source Url"
+ },
+ "state": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "State when known; null is not nationwide coverage.",
+ "title": "State"
+ }
+ },
+ "required": [
+ "carrier",
+ "state",
+ "kind",
+ "filer",
+ "docket",
+ "filed_at",
+ "granted_at",
+ "retirement_effective_at",
+ "geography_detail",
+ "source_url"
+ ],
+ "title": "CopperFiling",
+ "type": "object"
+ },
+ "CopperRecord": {
+ "description": "State-level carrier program status, not an address-specific deadline.",
+ "properties": {
+ "carrier": {
+ "description": "Normalized carrier identifier.",
+ "title": "Carrier",
+ "type": "string"
+ },
+ "notes": {
+ "description": "Scope and limitations of the state-level entry.",
+ "title": "Notes",
+ "type": "string"
+ },
+ "retirement_date": {
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Filed retirement date, or null when not established.",
+ "title": "Retirement Date"
+ },
+ "state": {
+ "description": "Two-letter US state abbreviation.",
+ "title": "State",
+ "type": "string"
+ },
+ "status": {
+ "description": "Program status.",
+ "enum": [
+ "date_filed",
+ "program_active"
+ ],
+ "title": "Status",
+ "type": "string"
+ }
+ },
+ "required": [
+ "carrier",
+ "state",
+ "retirement_date",
+ "status",
+ "notes"
+ ],
+ "title": "CopperRecord",
+ "type": "object"
+ }
+}Output schema / additionalPropertiesRemoved value: -trueOutput schema / descriptionAdded value: +"Citable program data and separately dated, reviewed filings."Output schema / propertiesAdded value: +{
+ "as_of": {
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "As-of date of static records, not of latest_filings.",
+ "title": "As Of"
+ },
+ "latest_filings": {
+ "description": "Up to 20 reviewed matching filings.",
+ "items": {
+ "$ref": "#/$defs/CopperFiling"
+ },
+ "title": "Latest Filings",
+ "type": "array"
+ },
+ "license": {
+ "const": "CC BY 4.0",
+ "description": "Reuse license; attribution is required.",
+ "title": "License",
+ "type": "string"
+ },
+ "records": {
+ "description": "Carrier/state entries matching the filters.",
+ "items": {
+ "$ref": "#/$defs/CopperRecord"
+ },
+ "title": "Records",
+ "type": "array"
+ },
+ "source": {
+ "description": "Source methodology and limitations.",
+ "title": "Source",
+ "type": "string"
+ },
+ "source_url": {
+ "description": "Attribution URL for the published dataset.",
+ "title": "Source Url",
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "records",
+ "source",
+ "source_url",
+ "license",
+ "as_of",
+ "latest_filings"
+]Output schema / titleAdded value: +"CopperResponse"request_broker_callback19 fields changedInput schema / properties / contact_email / descriptionAdded value: +"Email the user explicitly consented to share."Input schema / properties / contact_email / maxLengthAdded value: +255Input schema / properties / contact_email / minLengthAdded value: +3Input schema / properties / contact_email / patternAdded value: +"^[^@\\s]+@[^@\\s]+\\.[^@\\s]+$"Input schema / properties / contact_name / descriptionAdded value: +"Name the user consented to share."Input schema / properties / contact_name / maxLengthAdded value: +255Input schema / properties / contact_name / minLengthAdded value: +1Input schema / properties / contact_name / patternAdded value: +"\\S"Input schema / properties / session_id / descriptionAdded value: +"Workspace ID returned by the advisor."Input schema / properties / session_id / patternAdded value: +"^[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}$"Input schema / properties / session_token / descriptionAdded value: +"Private workspace credential."Input schema / properties / session_token / maxLengthAdded value: +512Input schema / properties / session_token / minLengthAdded value: +1Input schema / properties / session_token / patternAdded value: +"^\\S+$"Output schema / additionalPropertiesRemoved value: -trueOutput schema / descriptionAdded value: +"Recorded callback acknowledgement; this is not a confirmed appointment."Output schema / propertiesAdded value: +{
+ "book_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Optional scheduling link; booking is not required.",
+ "title": "Book Url"
+ },
+ "disclosure": {
+ "description": "Human-review disclosure supplied by the backend.",
+ "title": "Disclosure",
+ "type": "string"
+ },
+ "status": {
+ "const": "received",
+ "description": "Callback request recorded, not yet completed.",
+ "title": "Status",
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "status",
+ "book_url",
+ "disclosure"
+]Output schema / titleAdded value: +"CallbackResponse"ask_sync_advisorcheck_copper_retirementrequest_broker_callbackUS telecom availability and intelligence by address, with FCC provenance. Fiber-first.
Machine-readable FCC pre-diligence corpus for multifamily broadband infrastructure scenarios.
Live outage status, internet dependencies and pay-per-call market intelligence for AI agents.
Which M&A Advisor: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not...
Add one secure layer between your agents and this server.
