AI SENSE Free Public Tools

Free Public REST APIs - AI SENSE AS

No API key | No sign-up | No cost

Provided by AI SENSE AS (Oslo, Norway). Full endpoint reference: API.md | Repo: github.com/aisenseapi/aisense-free-public-rest-apis

Base URL: https://aisenseapi.com/services/v1/

Free public MCP endpoints

The AI SENSE MCP server is at:

https://aisenseapi.com/mcp

The AI SENSE MCP server covers Heartbeat, Lease, Agent Wake tasks, Agent Inbox, human approval, webhook capture, temporary storage, URL shortening, time and UUIDs. It needs no account or API key. Heartbeat uses create_heartbeat, read_heartbeat and ping_heartbeat. Lease uses create_lease_namespace, acquire_lease, renew_lease, release_lease and complete_lease. Agent Inbox uses create_agent_inbox and read_agent_inbox. See MCP.md for the tool list, data boundary and client examples.

The Agent Queue tools use separate read, write and worker tokens issued at creation. The semantic search tools use a read token and a write token in the same way.

Start with AGENT-GUIDE.md to choose tools, then AGENT-QUICKSTART.md for a complete Queue workflow and retry decisions.

The server reports version 1.13.1. It offers the workflow tools and one tool for each REST endpoint below. The official MCP Registry lists com.aisenseapi/free-public-tools version 1.13.1 as active and latest, published 6 October 2026 at 14:05 UTC.

aamio has its own MCP endpoint at https://aamio.at/mcp, eleven tools for ephemeral agent rendezvous: a thread with a secret read key and a public write address, a receipt of hashes that outlives it, presence, and the open board of needs and offers at https://board.aamio.at/. No account and no API key. The official MCP registry lists it as at.aamio/aamio. The AI SENSE endpoint does not proxy these tools either.

Verifyum has its own dedicated MCP endpoint at https://api.verifyum.com/mcp. It exposes the three Verifyum proof operations without an account or API key. File hashing still happens on the agent's machine. The browser flow, public HTTP API and published protocol remain available. The official MCP registry lists it as com.verifyum/mcp version 0.1.0. Finalized proofs also join hourly and daily Merkle checkpoints in the Verifyum Witness Layer. Nine records surround each finalized proof.

The Solana transaction is the primary evidence. Deep Solana history generally requires an archival provider. Glasklar, Mullvad and Tillitis cosign the Sigsum digest with a quorum of two out of three. The qualified timestamp uses RFC 3161. Its eIDAS Article 41(2) presumption covers the daily checkpoint root alone. A Verifyum user proof is not a qualified electronic timestamp. Verifyum is not a qualified trust service. Software Heritage and Internet Archive show what was stored. They do not establish when the original file existed. The number of channels is not a quality score.

Every finalized proof is also announced on Telegram and in the Atom feed. These are announcement channels. They are excluded from the nine evidence records. Their timestamps date the announcement. They say nothing about the original file date.

An agent can also assemble one decision record locally from its instructions, prompt, model, parameters, tool calls and output, then anchor only the commitment. The proof shows that the exact record existed unchanged by the block time. It does not prove that the model actually ran with the recorded settings.

Free public Agent2Agent (A2A) endpoint

Agents that speak Agent2Agent can reach five of these capabilities at:

https://aisenseapi.com/a2a

JSON-RPC 2.0, protocol revision 1.0, no account and no API key. The agent card is a plain GET at https://aisenseapi.com/.well-known/agent-card.json.

A2A is the protocol for delegating work to another agent. MCP is the protocol for exposing tools. Most of this service is tools, so only the five task-shaped capabilities are offered over A2A: agent-wake, human-approval, agent-inbox, webhook-capture and agent-queue. The other tools are not reachable through it. MCP stays the richer workflow surface with its own tool schemas. Over A2A the queue skill creates a queue and returns its three role tokens; enqueueing, claiming and acknowledging stay on REST and MCP.

A2A puts no skill id on the wire, so the caller names the skill in a data part of the message, as {"skill": "agent-wake", "arguments": { ... }}. That is a convention this service documents, not a field the protocol defines, and a message without it is refused. The card declares streaming and pushNotifications false, so those methods answer -32004 and -32003. ListTasks returns an empty page, because nobody is authenticated and a task ID is the only credential there is. See API.md for the skills, task states, response shapes and error codes.

SpeedUp (.su) - token cost, measured properly

Every serialization format marketed for LLM input ships a token-saving claim measured against a single tokenizer. Agent traffic crosses vendors, so we measured instead of assumed: six formats and 33 single-construct probes, priced by five vocabulary families (OpenAI o200k, DeepSeek, Qwen, SentencePiece, Tekken), with each provider's own token counter as ground truth.

• SU-PROFILE.md - the SpeedUp profile: eight writing conventions for agent-to-agent text, each citing its measured price tag
• speedup/ - the measurement rig (Python, standard library only), corpus, probes and raw numbers; rerun everything with your own keys
• The study - what survived measurement, what did not, and why we decided against shipping yet another format

Headline numbers: plain TSV averages 0.82x minified JSON across the five-vocabulary union and beats the token-oriented formats on every model; declaring columns once and sending values positionally is the entire mechanism (minus 34 percent per key-value pair); base64 costs 3.9-4.6x the plaintext it encodes; and single-letter key dictionaries lose to full keys on four of five vocabularies.

Why this exists

Most utility APIs require sign-up, rate limit tiers, or pricing for basic operations. This collection skips all of that. Drop a URL into curl, Python, JavaScript, or an LLM tool definition and it just works.

The collection covers two tiers of usefulness:

• Workflow endpoints - the ones that solve real problems in pipelines and agent systems
• Standard utilities - hashing, encoding, UUIDs, time, crypto - the building blocks

Three things to know before you write a client

These are service-wide and they decide how your error handling has to look.

The response key is named after the endpoint. /md5_hash returns md5_hash, /random_color returns random_color, /ping returns ping. There is no generic data or result wrapper. Do not guess the key - API.md lists every one.

Errors usually use {"error": "message"} with a non-2xx HTTP status. Check both the status and the error field. The legacy wallet-generation handlers can return an error object with HTTP 200. Workflow endpoints use non-2xx statuses, including 409 for conflicts and 410 for an expired record that has not yet been removed. Once removed, the same ID returns 404. Unknown routes also return 404. Consult each endpoint for its additional errors.

There is a rate limit: 5000 requests per IP per day. Exceeding it returns HTTP 429 in the same flat error shape as everything else. The count resets at 22:00 UTC from late March to late October and at 23:00 UTC the rest of the year (midnight in Norway, time zone Europe/Oslo), and the 429 carries Retry-After with the seconds until then.

The high-value endpoints

Heartbeat - know when a worker stops checking in

Create a monitor with an expected check-in interval, a grace period and one action for a missed deadline. The action can POST to a public webhook or wake an existing Agent Wake webhook task.

curl -X POST https://aisenseapi.com/services/v1/heartbeat \
  -H "Content-Type: application/json" \
  -d '{
    "expect_every_seconds": 300,
    "grace_seconds": 60,
    "on_miss": {
      "url": "https://example.com/agent-offline",
      "payload": { "agent": "worker-7" }
    }
  }'

The response gives you an unguessable heartbeat_id, ping_url and status_url. Call the ping URL with POST after each successful cycle. Each ping moves the expected deadline. It does not move the fixed 24-hour expiry. A missed deadline fires once, with no retry.

MCP clients can use create_heartbeat, read_heartbeat and ping_heartbeat for the same state.

Webhook destinations are checked for SSRF at creation and delivery. Private and reserved addresses, URL credentials, fragments and redirects are blocked. See API.md for the states and response fields.

Lease - one winner for shared agent work

Lease coordinates workers without an account. Mint a private namespace, then claim a key for a short period:

curl -X POST https://aisenseapi.com/services/v1/lease/namespace \
  -H "Content-Type: application/json" -d '{}'

curl -X POST https://aisenseapi.com/services/v1/lease \
  -H "Content-Type: application/json" \
  -d '{
    "namespace": "ns_...",
    "key": "invoice:2026-09-05",
    "ttl_seconds": 60,
    "fingerprint": "charge-order-501"
  }'

The winner receives an owner_token and a monotonic fencing_token. A second worker receives HTTP 409 while the lease is held. The owner can renew, release or complete the lease with a JSON result. Later callers with the same key and fingerprint can reuse that completed result.

The lease has a fixed absolute expiry 24 hours after its first acquisition. Renewals cannot extend it. Raw keys, namespaces, owner tokens and fingerprints are not stored. See API.md for the full acquire and completion flow.

The matching MCP tools are create_lease_namespace, acquire_lease, renew_lease, release_lease and complete_lease.

Agent Queue - share temporary work

Agent Queue gives producers and workers a shared queue for small JSON jobs.

curl -X POST https://aisenseapi.com/services/v1/queue \
  -H "Content-Type: application/json" -d '{}'

curl -X POST https://aisenseapi.com/services/v1/queue/QUEUE_ID/jobs \
  -H "Authorization: Bearer WRITE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"job_key":"report:42","payload":{"report_id":42}}'

curl -X POST https://aisenseapi.com/services/v1/queue/QUEUE_ID/claim \
  -H "Authorization: Bearer WORKER_TOKEN" \
  -H "Content-Type: application/json" -d '{"visibility_timeout":60}'

Replace the uppercase placeholders with creation response values. Keep the three tokens: they are issued only once. A claim returns one job with a secret receipt, or job: null when empty. The worker performs the work, then posts {"receipt":"RECEIPT"} to /queue/QUEUE_ID/jobs/JOB_ID/ack using its worker token. It can release or renew an active claim with the same receipt. Observers read queue counts and individual jobs with the read token. Credentials belong in headers, never in URLs.

The queue and every job expire exactly 24 hours after queue creation. Enqueue, claims, renewals and completion never extend that deadline. Limits are 100 distinct jobs over the queue lifetime, 16 KiB of encoded JSON per job, five claim attempts, and 20 new queues per client IP per 24 hours. Visibility is 30 to 900 seconds, default 60. Repeating a job key and payload returns the existing job. A changed payload conflicts.

Jobs can be delivered again after a claim expires or is released. Queue expiry and the attempt limit may leave jobs unfinished. Initial delivery and exactly-once execution are not guaranteed. Make external actions idempotent. The service holds the queue state and does not run jobs, fetch URLs or send callbacks.

MCP clients use the eight queue tools. A2A clients name the agent-queue skill, which creates the queue and returns its three role tokens; enqueueing, claiming and acknowledging stay on REST or MCP.

See the Queue API reference, MCP tools and website guide.

Semantic search - find earlier notes by meaning

Semantic search keeps short notes from agents in a collection for 24 hours and finds them by meaning, across wording and between languages.

curl https://aisenseapi.com/services/v1/semantic_search

curl -X POST https://aisenseapi.com/services/v1/semantic_search/COLLECTION_ID/notes \
  -H "Authorization: Bearer WRITE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"notes":[{"text":"Suspicious login attempts from many addresses on the admin page.","key":"incident:17"},{"text":"Mange mislykkede innlogginger mot adminsiden i natt."}]}'

curl -X POST https://aisenseapi.com/services/v1/semantic_search/COLLECTION_ID/search \
  -H "Authorization: Bearer READ_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"brute force attack on the admin login"}'

Creation returns the collection ID with a read token and a write token, shown only once. The default model is bge-m3. POST {"model":"qwen3-embedding-4b"} to /semantic_search to use the other one. A search answers ranked suggestions with note_id, key, text and score, never a decision that a match exists. The score is cosine similarity plus 0.1 per identifier, such as DEMO-57 or an amount, that search and note share, and it is not a probability.

The collection expires exactly 24 hours after creation. Limits are 500 notes over that lifetime, 2000 characters per note, 20 new collections per client IP per 24 hours, and 60 searches or additions per minute and 1000 per UTC day per IP. Keep secrets and sensitive personal data out of notes.

Agent Wake - resume after an outside event

Create one task that waits for a webhook, a human answer or a chosen time. MCP clients use the current Tasks extension and poll tasks/get. REST clients use POST /agent_wake and the returned status URL. A2A clients name the agent-wake skill and poll GetTask, which is the one skill that answers with an A2A Task rather than a Message.

{ "event_type": "webhook", "timeout_seconds": 3600 }

The result contains an unguessable task ID and a wake URL. The first request to that URL completes the task. Human tasks create a hosted form. Time tasks complete on the first read after the selected timestamp. Each task expires in 60 seconds to 24 hours.

REST clients can wait for a terminal state with GET /agent_wake/{task_id}/wait/{seconds}. The final value accepts 0 to 25.

See MCP.md for the task flow, and API.md for the REST calls and the A2A skill.

Webhook Action - human-in-the-loop for agents

The standout endpoint for AI and automation work. When an automated pipeline needs a human decision before continuing, this handles the whole pattern with zero backend setup.

How it works:

1. POST a form definition (radio buttons, dropdowns, text fields, checkboxes)
2. Get back a form_url, result_url and wait_url
3. Send the form_url to a human via email or Slack
4. Read result_url, or use wait_url to wait up to 25 seconds

curl -X POST https://aisenseapi.com/services/v1/webhook_action \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Approve deployment to production?",
    "fields": [
      {
        "type": "radio",
        "name": "decision",
        "label": "Decision",
        "required": true,
        "options": [
          { "value": "approve", "label": "Approve" },
          { "value": "reject", "label": "Reject" }
        ]
      },
      { "type": "textarea", "name": "comment", "label": "Notes (optional)" }
    ]
  }'

{
  "ok": true,
  "action_id": "9e0e6d3b-1a45-44c5-9e0b-92f5f3bdb2f1",
  "form_url": "https://aisenseapi.com/services/v1/webhook_action/9e0e6d3b-.../form",
  "result_url": "https://aisenseapi.com/services/v1/webhook_action/9e0e6d3b-...",
  "wait_url": "https://aisenseapi.com/services/v1/webhook_action/9e0e6d3b-.../wait/25",
  "expire_timestamp": 1786959912,
  "expire_datetime": "2026-08-17T09:45:12Z"
}

Poll for the answer:

curl https://aisenseapi.com/services/v1/webhook_action/{action_id}
# "status": "pending" -> "answered", with the submission under "response"

Field types: radio, select, text, textarea, checkbox. options accepts plain strings or {"value": ..., "label": ...} objects. Expires after 24 hours.

Add respondents from 2 to 20 for separate one-use form links. The result then moves through pending, partial and answered, with answer counts, a tally and individual responses. Add notify_url when you want one completion signal that points back to the result without copying the answers.

MCP clients use create_human_approval and read_human_approval. A2A clients name the human-approval skill, which creates the form and returns its URLs; reading the answer stays on REST or MCP.

Webhook Capture - inspect any inbound HTTP request

Create a capture, get a unique URL, point any external service at it (Stripe, GitHub, Shopify), and read back the full request - method, headers, query parameters, IP, and parsed body. No ngrok, no local tunnel, no server.

# 1. Create a capture
curl -X POST https://aisenseapi.com/services/v1/webhook_capture
# -> { "status": "pending", "capture_id": "...", "update_url": "...", "read_url": "...", "wait_url": "..." }

# 2. Point your webhook sender at update_url, with any HTTP method
curl -X POST {update_url} -H "Content-Type: application/json" -d '{"event":"payment.created"}'

# 3. Wait up to 25 seconds for the first request
curl https://aisenseapi.com/services/v1/webhook_capture/{capture_id}/wait/25

{
  "ok": true,
  "capture_id": "6f8c9e52-...",
  "captured_at_timestamp": 1786873316,
  "captured_at_datetime": "2026-08-16T09:41:56Z",
  "request": {
    "method": "POST",
    "uri": "/services/v1/webhook_capture/6f8c9e52-.../update",
    "headers": { "content-type": "application/json" },
    "client_ip": "203.0.113.10",
    "body": { "json": { "event": "payment.created" }, "text": null, "base64": null, "raw_length": 28 }
  }
}

Expires after 24 hours.

The first inbound request wins and later retries cannot replace it. Captured bodies are capped at 256 KB. The create body may contain notify_url for one completion signal.

MCP clients use create_webhook_capture and read_webhook_capture. A2A clients name the webhook-capture skill, which creates the capture and returns its URLs; reading the request stays on REST or MCP.

Agent Inbox - a disposable mail address the agent controls

For the step where something has to arrive by email: a verification code, a confirmation link, a sign-up mail. Create an inbox, hand out the address, read the mail back as cleaned text. No account, no API key, and it lasts at most 24 hours.

curl https://aisenseapi.com/services/v1/inbox

{
  "ok": true,
  "inbox_id": "a85d0bee-f8f7-4be1-a1b3-8d58f3dbdf