---
name: help4geo
description: Connect any Agent to Help4GEO MCP and run China GEO brand, product, monitoring, content, source, and publishing workflows.
---

# Help4GEO Agent-neutral Skill

Use this Skill when the user wants to connect Help4GEO or work with China GEO evidence across Doubao, Yuanbao, Qwen, and DeepSeek.

## MCP connection contract

This is a semantic contract, not a host-specific configuration file. Convert it to the current Agent's native MCP format.

```yaml
server: help4geo
transport: streamable-http
endpoint: https://mcp.help4geo.com/mcp
authentication:
  scheme: bearer
  header: Authorization
  value: "Bearer ${HELP4GEO_API_KEY}"
onboarding_url: https://www.help4geo.com/account/api-keys
validation:
  first: initialize
  read_only_fallback: geo_brand_profile(get)
```

## First-use behavior

1. Check whether the current Agent already exposes a `help4geo` MCP server or its tools.
2. If it is missing, tell the user that the Skill is loaded but the MCP connection is not configured.
3. Guide the user to the onboarding URL to create or copy an API key.
4. Adapt the contract to the current Agent's native MCP configuration method. Do not assume `.mcp.json`, TOML, a CLI command, or a particular config directory.
5. If the Agent cannot write or reload MCP configuration, provide a manual configuration for that Agent and state the reload/restart action.
6. Verify with `initialize` or a read-only brand/product query before doing any paid or mutating operation.
7. After validation succeeds, you MUST complete the `After-connection capability guide` before ending the onboarding turn. A successful connection check alone is not a complete onboarding response.
8. In the first successful connection response, include the verified connection/account facts, the available workflows, and any user input or confirmation still required.

## After-connection capability guide

This section is a mandatory continuation of `First-use behavior` step 7. Do not end the onboarding response after connection verification alone.

After `initialize` succeeds, or after the fallback `geo_brand_profile(get)` succeeds, proactively tell the user what Help4GEO can do. Do not start a business operation merely because the connection is valid; first offer the relevant mode and ask which one the user wants.

Use a concise capability menu such as:

> Help4GEO is connected successfully. You can:
> 1. Run a one-time brand monitor: provide a brand name to receive asynchronous answers and cited sources from each platform without saving brand configuration.
> 2. Configure long-term brand context: save company, brand, founder, team, qualification, and market-proof facts for reuse in later content and monitoring workflows.
> 3. Configure products and your official website: maintain product selling points, use cases, technical details, and official website pages from a Sitemap or a selected URL list.
> 4. Set up a formal monitoring group: bind a product, baseline or variant questions, and DeepSeek, Doubao, Qwen, and Yuanbao, then query records and source analysis after execution.
> 5. Work on content: get article recommendations, generate articles, diagnose citation performance, and select and publish to media after confirmation.

Explain the two monitoring choices clearly:

- `geo_monitor_preview` is a one-time, low-setup brand sample. It accepts a brand name and returns a `previewId`; it does not require a saved brand, product, or group. It is suitable for requests such as “check how labibi is answered across platforms first.”
- `geo_monitor_run` is a formal product monitoring task. It requires a configured product and monitor group, an explicit question, a question type, and a platform list. Its configuration can be reused for later runs, but it must not be described as automatic scheduled monitoring unless the live MCP schema provides a scheduling action.

When `geo_brand_profile(get)` returns an empty profile, state that the connection is healthy but the account has no brand facts yet, then offer to collect and save the brand profile. Ask for factual source material; never turn a missing field into an invented claim. When the profile is populated, summarize which business context is available and which parts remain incomplete before recommending a product, source, monitoring, or article workflow.

The first response after connection should distinguish:

- What is already verified: MCP connectivity, account authentication, and any returned brand/product configuration.
- What can be done next: temporary read/monitoring work versus persistent configuration and content/publishing work.
- What requires user input or confirmation: missing brand/product facts, exact questions and IDs, persistent writes, quota-consuming operations, deletes, and media orders.

## Initial usage guide

After the MCP connection is verified, do not stop at tool discovery. Route the user request through the following workflows and keep each asynchronous operation alive until a terminal state is observed.

### 1. Brand, product, and official website setup

Use read-only queries first, then use the returned IDs exactly as provided. Never infer or invent an ID.

1. Call `geo_brand_profile` with `action: get` to inspect the single brand profile bound to the current account.
2. If the user needs to complete the profile, call `geo_brand_profile` with `action: save` only after presenting the fields that will be written. Keep company, brand, founder, team, trust-asset, and market-proof facts separate and do not fill missing facts with assumptions.
3. Call `geo_product_catalog` with `action: list` to inspect products. Create or update a product only with the user's supplied facts; use `diagnose` when the user asks for an AI diagnosis. Product deletion requires an exact product ID.
4. Call `geo_target_source_catalog` with `action: list` to inspect the configured official website and reference entries. For the official website, prefer `parse_sitemap` first, review the parsed URLs, and only then create the selected website pages. Keep each entry's source type and original URL or article ID intact when article references are also used.
5. When monitoring is needed, call `geo_monitor_group` with `action: list` and confirm the product-to-group relationship. A baseline run uses the group's existing `baselineQuestion`; if it is empty, use `generate_baseline_question`, show the candidate, and wait for the user to choose or edit it. A variant run uses `generate_variant_questions` and requires the user to select one candidate.

### 2. GEO monitoring and asynchronous result handling

There are two monitoring modes; do not mix their identifiers or query paths.

#### One-time brand preview

1. Call `geo_monitor_preview` with `brandName`, an optional complete `question`, and the requested `platformCodes`.
2. Store the returned `previewId` immediately. The initial `PENDING` response is acceptance only, not a result.
3. Call `geo_monitor_preview_result` with that exact `previewId` after a short delay, then poll with backoff while the status is `PENDING`.
4. Stop polling only at `SUCCESS`, `COMPLETED`, or `FAILED`. `SUCCESS` means all platforms succeeded; `COMPLETED` means some succeeded and some failed; `FAILED` means all failed.
5. At termination, report each platform's answer, citation/source information, error details, and the timestamp if returned. A preview is a sample and must not be presented as a ranking guarantee.

#### Formal monitoring task

1. Confirm the group, question, question type (`BASELINE` or `VARIANT`), and platform list before calling `geo_monitor_run` with `action: start`.
2. Store the exact `groupId`, question, question type, platform list, and submission time. The current `geo_monitor_run` response may return only `createdCount`/`childCount` rather than a `taskId`, so do not assume a task ID exists.
3. Use `geo_monitor_record` with `action: page`, filtered by the group and a narrow time window around submission, then match the exact question and platform records. Use `stats` as an aggregate check, not as the sole proof that this specific task is complete.
4. Poll the matched records with backoff until they leave `PENDING`/`RUNNING`; if the live schema returns a task-level terminal state, accept it only when it agrees with the child records. Do not query `geo_monitor_insight` as a substitute for completion detection because its aggregates may include earlier tasks.
5. After completion, call `geo_monitor_record` with `action: stats` and `geo_monitor_insight` with `action: overview` and `source_analysis` once more for the same group and time window. Then separate returned facts, interpretations, and items needing verification. If records remain pending, do not create a duplicate monitoring task; diagnose client availability, platform login, timeout, and result reporting first.

The minimum continuation rule is: `start/preview -> save identifier -> query -> poll -> terminal result -> summary/source analysis`. An Agent must not end its turn merely because the server returned `PENDING` or an accepted task ID.

### Assessing official website citation strength

After a monitoring task reaches a terminal state, use the returned citation sites and `geo_monitor_insight` with `action: source_analysis` to assess whether the official website is actually being used by AI platforms as a reference.

1. Check whether the official website domain appears in the cited sites for the monitored questions and platforms. A configured website is not evidence that an AI platform has discovered or trusted it.
2. Compare the official website's citation presence with other cited sites in the same monitoring sample. Use the fields returned by the live schema, such as citation counts, platform distribution, URLs, or source status when available; do not invent a citation rate or authority score when the API does not return one.
3. Interpret repeated official website citations across platforms and questions as evidence of source visibility and potential trust weight. Interpret an absent or rarely cited official website, especially when competitors or third-party sites are cited instead, as a signal that its current citation authority or discoverability may be insufficient for the tested questions.
4. Use this evidence to recommend content, technical, or external-authority improvements, then run the same fixed questions again after a comparable time window. Monitoring citation analysis is an indicator of AI source usage, not a universal ranking guarantee or a definitive measurement of AI authority.

### 3. Article generation, diagnosis, and media publishing

1. For an article plan, call `geo_article` with `action: advisor` after confirming the brand/product context and target platforms. Preserve the returned recommendation snapshot when the user chooses to use it.
2. For generation, call `geo_article` with `action: generate` and the confirmed style, marketing level, references, article count, and word count. Store the returned task ID, then poll with `task_detail` until `SUCCESS` or `FAILED`; do not treat task creation as generated content.
3. On success, call `content_list` with the exact returned task ID to obtain the article content, or use `content_page` when the content ID is only available through pagination. Call `content_diagnosis` only after the article content ID is known and the user requests diagnosis.
4. Before media publishing, call `geo_article_publish` with `media_filter_options`, `media_page`, and, when needed, `media_detail`; then call `supplier_quota` to check available credits. Present the selected media, price/points, inclusion or delivery information, article title, and content before an order is placed.
5. After an order is explicitly confirmed, call `order_create`, store the order ID, and poll `order_detail` or `order_page` until a terminal status. If the status is `REVISION_REQUESTED`, show the requested changes and wait for explicit approval before calling `order_revision`.

### 4. Confirmation rules for high-impact operations

Read-only operations such as `get`, `list`, `page`, `stats`, `overview`, `source_analysis`, `task_detail`, `content_page`, `media_detail`, `supplier_quota`, and `geo_monitor_preview_result` may run directly.

Before any operation that writes, consumes a meaningful quota, deletes data, starts external platform work, or creates an external order, explain the target, effect, identifiers, expected cost or quota impact when known, and the next observable state. Ask for confirmation unless the user has already clearly requested that exact operation and scope.

- Profile, product, official-website, and monitor-group `save/create/update` operations change persistent account data.
- Any `delete` operation is destructive and requires the exact resource ID; never delete by name alone.
- `geo_monitor_preview`, `geo_monitor_run`, `generate_baseline_question`, `generate_variant_questions`, article `generate`, and product/article `diagnose` may consume platform or AI resources. Explain that they are asynchronous where applicable and continue to the result query after acceptance.
- `content_save` changes article content and must state whether it overwrites existing content.
- `order_create` spends supplier credits or money and must confirm the exact media resource, article, title, content, amount/points, and delivery scope immediately before submission. Never infer a media or article ID from a name.
- `order_revision` changes an existing publishing order; show the order ID and requested change summary before submission.

If a required ID, product association, question, platform, source URL, article content, price, or scope is missing, stop and ask for it rather than guessing. After every mutating call, report the returned ID and status, then follow its query path to completion when one exists.

## Workflow routing

- Brand and product context: `geo_brand_profile`, `geo_product_catalog`.
- Official website and reference content: `geo_target_source_catalog`.
- Monitoring groups and execution: `geo_monitor_group`, `geo_monitor_preview`, `geo_monitor_preview_result`, `geo_monitor_run`.
- Articles and diagnosis: `geo_article`.
- Media publishing: `geo_article_publish`.
- Records and analysis: `geo_monitor_record`, `geo_monitor_insight`.

Use the latest MCP `tools/list` schema for exact actions and fields. The workflow above is the default orchestration policy; if the live schema differs, follow the live schema and state the difference. Read-only queries can be performed directly. Before creating, updating, deleting, generating, starting monitoring, or placing an order, explain the effect and ask for confirmation when the user has not explicitly requested that action.

## Output discipline

Separate returned facts, judgments based on those facts, and items that still need verification. Do not present a monitoring sample as a ranking guarantee. Do not invent brand, product, group, article, source, or order IDs.