FCC copper retirement lookups and a broker-reviewed IT advisor. No supplier names, no prices.
Scored across 3 tools
Each tool serves a clearly distinct purpose: consulting the advisor, performing a deterministic data lookup, and requesting a human callback. No two tools overlap in function or output.
All three tool names follow the same verb_noun pattern: ask_sync_advisor, check_copper_retirement, request_broker_callback. The naming is uniform and predictable.
Three tools is well-scoped for this server's narrow domain: advisory consultation, a specific lookup, and a human handoff. Each tool earns its place with no redundant surface.
The tool set covers the full workflow: start and continue the advisor conversation, query retirement status data, and request broker follow-up. No obvious gaps exist for the stated purpose.
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?
All four annotations are false, so the description carries the full burden of behavioral disclosure, and it delivers richly. It discloses that a private workspace is created (a write), that the tool is stateful and requires returned credentials for continuation, that incomplete continuation handles are rejected before any write, that a failed write may already have been recorded (non-idempotent), and that replies never include supplier names or pricing — which arrive only via claim_url or callback. This is precisely the kind of behavioral context an agent needs on top of empty 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 dense — roughly 180 words — but every sentence earns its place given the tool's stateful nature and absent annotations. It is effectively front-loaded (purpose first, then lifecycle, then safety rules, then output constraints). Some hints (e.g. 'required with session_id') are already in the schema and slightly redundant, but there is no wasted 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 complex, stateful, 6-parameter tool with no annotation support, the description covers every decision point an agent faces: how to start, how to continue, how to recover from incomplete handles, how to avoid duplicate writes, and what the output will and will not contain. An output schema exists, so return-value details are already provided elsewhere. Nothing an agent needs to call this correctly 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 coverage is 100%, setting the baseline at 3. The description goes beyond the individual field descriptions by explaining the interplay: it clarifies that pain and company_name are required only for a new workspace, session_id/session_token are returned credentials needed together for continuation, and conversation_id is required for follow-up turns. This on-boarding/continuation pairing semantics adds meaning the schema's per-field descriptions do not convey on their own.
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 opening line 'Consult CHNLSYNC's advisor about the user's IT environment' uses a specific verb (consult) with a clear resource (the advisor) and a defined domain (the user's IT environment). The focus on advising about IT environment clearly distinguishes it from siblings like check_copper_retirement (retirement checks) and request_broker_callback (callback scheduling), which are plainly different 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?
The description gives exceptionally explicit usage guidance: it distinguishes the first call (provide pain + company_name, omit session fields) from continuation calls (pass session_id, session_token, and conversation_id), and instructs persisting all three privately across turns. It even offers a recovery path (recover previous tool result instead of creating another workspace) and a warning never to auto-retry failed writes. The only gap is that it never names sibling alternatives or states when NOT to use this tool in favor of them.
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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it is a deterministic read of an FCC-sourced dataset, requires citation of the returned source_url, and clarifies that the data is from CHNLSYNC. This goes beyond the annotations and helps the agent understand the nature of the operation.
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 compact and front-loaded: the first sentence states the purpose, the second adds usage details and the citation requirement. Every sentence earns its place, and there is no redundant or filler content.
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?
The tool has an output schema, so return values are already documented. The description covers the key usage details: what the tool does, how to filter, and the citation requirement. It could arguably mention that the dataset is FCC-sourced in the first sentence, but the current structure is sufficient for an agent to call it correctly.
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 documents both parameters. The description adds value by explaining that carrier accepts display names and state is a two-letter abbreviation, and by noting that omitting both returns the full dataset. This is a small but useful addition beyond the schema.
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 ('Look up'), a clear resource (US copper/POTS retirement program status), and the key dimensions (carrier and state). It also distinguishes itself from siblings by being a deterministic read of a specific dataset, which is not apparent from the tool name alone.
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 explicitly explains when to use this tool: to look up US copper/POTS retirement status by carrier and state, and notes that omitting both returns the full dataset. It also provides concrete input examples ('AT&T', 'Lumen', 'Frontier') and clarifies the state format, which is strong practical guidance. It does not explicitly name alternatives, but the sibling tools (ask_sync_advisor, request_broker_callback) are clearly different in purpose, so no exclusion is needed.
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 declare openWorldHint=true, idempotentHint=false, readOnlyHint=false, but the description converts those abstract flags into concrete agent-relevant behaviors: a real human will contact the user, a retried request may already be recorded, and the returned book_url is optional rather than mandatory. It also discloses the auth prerequisite beyond what readOnlyHint=false alone implies.
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 roughly four sentences with no fluff; the purpose and consent gate are front-loaded, followed by prerequisite, booking semantics, and retry rule. Every sentence earns its place — each constraint maps to a real failure mode (sharing personal data without consent, mis-marketing optional booking, double-submitting non-idempotent requests).
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 the description rightly doesn't narrate the return shape; instead it covers exactly what the schema can't: consent requirements, session-credential provenance, the optionality of book_url in the conversation, and timeout retry behavior. Combined with the coverage, an agent has everything needed to invoke this tool safely.
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 4 parameters are already documented with paired descriptions at 100% coverage (consent-scoped contact_name/contact_email, advisor-returned session_id, private session_token). The description adds the provenance breadcrumb that the session credentials come specifically from ask_sync_advisor, plus the consent framing — helpful but modest given how much the schema already carries.
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 action with verb, resource, and subject ('ask a CHNLSYNC human broker to contact the user about their case'). It is plainly distinguishable from siblings: ask_sync_advisor returns credentials, and check_copper_retirement checks retirement status — neither queues a human callback.
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?
Names the exact gate conditions: the user's explicit consent to share name/email, and the prerequisite session credentials 'returned by ask_sync_advisor' — explicitly routing the agent to the right sibling first. It also gives when-not-to: never present booking as required/confirmed, and never auto-retry after a timeout.
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.
Which M&A Advisor: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not...
Search U.S. cell plans, compare supported costs, find wireless news, and get switching guidance.
Add one secure layer between your agents and this server.
