Agentalog — Agent Auto Log

Submit OKF

submit_okf

Submits OKF bundles from a host you control (IndexNow protocol: a key file proves ownership, with no account). No charge. Answers 202 — the key is checked by the collector before anything is read. No account, no payment: ownership is proved by a key file on the host, exactly as IndexNow does it. Host https://<host>/<key>.txt containing the key (or point keyLocation at another path on the SAME host), then send the bundle URLs. We answer 202: the key has not been checked yet. Verification and reading happen on our collector, never at the edge — so nothing is published, and no URL of yours is fetched, before the key matches. Re-sending a URL is how you say the bundle changed; it goes back in line to be re-read. At most 100 URLs per request and 200 per host per UTC day. The same queue is served by POST https://okfindex.com/api/ping, the index's own home — search, bundle cards and statistics live there.

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": {
      "host": "<host>",
      "key": "<key>",
      "urlList": "<urlList>"
    },
    "name": "submit_okf"
  }
}

Input Schema

Name	Required	Description
`key`	Yes	8 to 128 characters of [a-zA-Z0-9-].
`host`	Yes	The host that owns the bundles.
`urlList`	Yes	Bundle `index.md` URLs. https, on `host`, ending in .md. No fixed path: the spec defines no discovery convention.
`keyLocation`	No	Where the key file lives. Defaults to `https://<host>/<key>.txt`; must be on `host`.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 8, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only cover readOnly/idempotent/destructive flags; the description goes well beyond them by disclosing the 202 response (key not yet checked), that verification and reading happen on the collector so nothing is published or fetched before the key matches, and hard rate limits of 100 URLs per request / 200 per host per UTC day. These are exactly the operational facts an agent needs and none are in the annotations.

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?

The critical facts (202, no charge, key verification deferred) are front-loaded, but the 'no account / no payment / no charge' point is repeated three times and the collector-vs-edge explanation is restated, padding a description that could be roughly half its length.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does so by explaining the 202 status and its meaning, plus rate limits and re-submission behavior. Error/status cases other than 202 and what a successful read eventually yields are left implicit.

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

Parameters3/5

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 already documented, and the description mostly restates them (key file path, keyLocation on the same host, .md URLs). It adds the useful framing that no discovery convention exists, but little else parameter-specific. Baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: submits OKF bundles from a host you control, with the IndexNow ownership model named. An agent can distinguish this from read-side siblings like search_bundles or get_bundle. 'OKF bundle' is jargon not defined anywhere, which keeps it from a 5.

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

Usage Guidelines4/5

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

Explains the precondition (key file on the host, optional keyLocation on the same host) and the re-submission semantics: re-sending a URL signals the bundle changed. It also notes the identical queue is reachable via POST https://okfindex.com/api/ping. It never explicitly excludes read paths or says 'do not use this to retrieve bundles'.

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

All Agentalog — Agent Auto Log tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.