Keytomic

Submit for indexing

submit_for_indexing

Submits URLs or sitemaps of the site to every connected engine and returns one entry for each engine: status accepted, skipped or failed, with reason and detail: the counts (each URL and sitemap is submitted, skipped or failed), sentSitemapUrls and skippedSitemapUrls, failures with the code and reason of each refused URL or sitemap, and for Bing the URL quota left. Google takes sitemaps only: with urls, Google gets the preferred sitemap of the site, as the Indexing page sends it, and is skipped with reason no_sitemap when the site has none. With sitemapUrls, every engine gets those sitemaps, and Google gets no other sitemap. With neither, every engine gets the known sitemaps of the site: the sitemaps found during setup, or /sitemap.xml of its domain. Google needs a connected account with Owner or Full permission. A Google failure is the Google entry, not a tool error: failed with detail.error, retryAfterSeconds when a retry can clear it and connectUrl when the user must fix the connection. A sitemap off the property is not sent; when no sitemap is on the property, Google is skipped with reason site_mismatch. Bing takes URLs and sitemaps. Each URL submit uses the Bing URL quota and a sitemap submit uses none. A URL or sitemap off the Bing site is not sent; when nothing is on the site, Bing is skipped with reason site_mismatch. After a Bing refusal that would repeat (bing_unauthorized, bing_throttled, bing_unavailable, bing_not_connected), Keytomic sends no more sitemaps to Bing and the reason is stopped (not_connected for bing_not_connected); after another refusal it continues. When no quota is left, Bing is skipped with reason quota_exhausted. An engine the site has not connected is skipped with reason not_connected. A failure of one engine does not stop the other. Spends no credits. Google and Bing read a submit later, so inspect_urls shows no change at once.

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": {
      "projectId": "<projectId>"
    },
    "name": "submit_for_indexing"
  }
}

Input Schema

Name	Required	Description
`urls`	No	Up to 50 URLs of the site. Duplicates are submitted once.
`projectId`	Yes	Site to act on, from list_sites. Its connected Search Console property and Bing Webmaster site are used.
`sitemapUrls`	No	Up to 50 sitemaps of the site to send to every engine.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already flag this as a non-read-only, open-world, non-idempotent, non-destructive call, and the description adds a great deal beyond that: credit cost ('Spends no credits'), Google account permission requirements, Bing URL quota consumption, per-engine failure isolation, and eventual consistency ('Google and Bing read a submit later, so inspect_urls shows no change at once'). It also distinguishes engine-level failure from tool-level error, which 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.

Conciseness3/5

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

Almost every sentence carries substantive behavior, but the text is one long colon-chained run-on with no paragraph breaks or bullets, which makes it laborious to parse for a three-parameter tool. Purpose is front-loaded correctly, yet the dense engine-by-engine rules would be far more usable as a structured list.

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?

There is no output schema, so the description carries the full burden of describing returns, and it does: per-engine statuses (accepted, skipped, failed), reasons, counts, failure codes, and Bing's remaining quota. Permission prerequisites, skip conditions, and eventual-consistency caveats are all covered, leaving nothing an agent needs before calling it.

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 each of the three parameters. The description compensates further by explaining the consequences of each combination: urls makes Google use the site's preferred sitemap or be skipped with no_sitemap, sitemapUrls sends exactly those sitemaps to every engine, and neither falls back to known or default sitemaps. That is real added meaning, though format-level details such as the 50-item cap live only in 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 opening clause names a specific verb and resource: 'Submits URLs or sitemaps of the site to every connected engine', and immediately states the per-engine result shape. An agent can tell this apart from read-only siblings like inspect_urls or get_indexing_status, which the description also references.

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

Usage Guidelines3/5

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

Usage is only implied through the parameter-behavior rules (with urls vs sitemapUrls vs neither), which effectively tell the agent how each call mode behaves. There is no explicit 'use this when / not this' routing against inspect_urls or get_indexing_status; inspect_urls is mentioned only to warn that it will show no change yet, not as an alternative to select.

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

All Keytomic 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.

Resources

Need Help?