Organiq GEO

Request indexing of URLs

request_indexing

Idempotent

Queues up to 100 URLs of one property for submission to search engines, by two routes: IndexNow (Bing, Yandex, Naver, Seznam, Yep; needs the IndexNow key set for the property) and Google through the Indexing API (optional per property). Google route (Indexing API) only sends pages with JobPosting or BroadcastEvent structured data, as Google requires; other URLs are checked at send time, not here: get_indexing_requests later shows them skipped, error starting google_not_eligible, and go through IndexNow when configured. Parameters: urls (absolute URLs of the property), action update (default) or delete, engines (indexnow and/or google; default: the configured routes). Returns queued (url + engine), skipped with a reason per URL (invalid_url, outside_property, duplicate_24h, daily_limit_indexnow, daily_limit_google, google_not_allowed_by_plan, google_not_configured, indexnow_not_configured) and creditsLeft ({indexnow, google}: URLs still allowed today on each route; null = no daily limit on that route). A submission is a request, not a confirmation: see get_indexing_requests and list_url_inspections. Writes only to Organiq (the request queue) and sends the URLs to the engines; never changes Search Console. Needs mcp:write. Errors: indexing_not_configured with the panel step; plan_limit only when no requested engine is allowed by the plan. A spent daily credit is not an error: the URLs come back in skipped (daily_limit_*). / Envia até 100 URLs para indexação (IndexNow e, opcional, Google Indexing API); grava só no Organiq e não altera o Search Console.

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": {
      "site": "<site>",
      "urls": "<urls>"
    },
    "name": "request_indexing"
  }
}

Input Schema

Name	Required	Description
`site`	Yes	Property: displayName ("example.com"), Search Console siteUrl ("sc-domain:example.com", "https://www.example.com/") or numeric id. A unique substring among visible properties also works ("exam"). list_sites shows the options. The value "demo" selects a demonstration site with fictional data: it works without signing in and is read-only. / Propriedade por nome, siteUrl ou id; "demo" é um site de demonstração com dados fictícios, sem login e só leitura.
`urls`	Yes	Absolute URLs inside the property, 1–100.
`action`	No	update (default): the URL was created or changed; delete: the URL was removed.
`engines`	No	Routes to use (default: the ones configured for the property).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedInput schema / properties / site / description

Previous value: -"Property: displayName (\"example.com\"), Search Console siteUrl (\"sc-domain:example.com\", \"https://www.example.com/\") or numeric id. A unique substring among visible properties also works (\"exam\"). list_sites shows the options. / Propriedade por nome, siteUrl ou id."New value: +"Property: displayName (\"example.com\"), Search Console siteUrl (\"sc-domain:example.com\", \"https://www.example.com/\") or numeric id. A unique substring among visible properties also works (\"exam\"). list_sites shows the options. The value \"demo\" selects a demonstration site with fictional data: it works without signing in and is read-only. / Propriedade por nome, siteUrl ou id; \"demo\" é um site de demonstração com dados fictícios, sem login e só leitura."

AddedOct 31, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Despite annotations already covering the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), the description adds substantial context: it writes only to the Organiq request queue, never changes Search Console, requires mcp:write, and explains error conditions and return shape. This goes well beyond what the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded, with key constraints stated first. It is longer than typical but every sentence carries useful information—route eligibility, skip reasons, return format, and error handling. The structure is a single long paragraph, which is slightly less scannable but still efficient.

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

Completeness5/5

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

For a mutation tool with no output schema, the description fully covers return values (queued, skipped, creditsLeft), error cases, and the distinction between a submission request and confirmation. It also specifies prerequisites (IndexNow key, mcp:write) and plan limits, making the definition complete for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all four parameters. The description enhances this by specifying default behavior for action (update) and engines (the configured routes), and by linking the engines parameter to the two available routes. It adds meaningful default semantics beyond the schema.

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

Purpose5/5

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

The description opens with a specific verb and resource: "Queues up to 100 URLs of one property for submission to search engines, by two routes." It explicitly names the two routes (IndexNow and Google Indexing API) and distinguishes this from sibling tools by pointing to get_indexing_requests and list_url_inspections for confirmation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit guidance on when each route applies (Google Indexing API only for JobPosting/BroadcastEvent URLs), what happens with ineligible URLs (skipped and shown later by get_indexing_requests), and directs the agent to list_url_inspections and get_indexing_requests for verification. It also clarifies that a spent daily credit is not an error and lists all skip reasons, leaving little to inference.

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

All Organiq GEO tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.