Aisense Free Public Rest Apis MCP Server

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.0. 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.0 as active and latest, published 4 October 2026 at 20:47 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 midnight Norwegian time (Europe/Oslo), 22:00 UTC in summer and 23:00 UTC in winter, 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-8d58f3dbdfc7",
  "slug": "ztjqt7n",
  "address": "aisense+ztjqt7n@aisenseapi.com",
  "read_url": "https://aisenseapi.com/services/v1/inbox/a85d0bee-f8f7-4be1-a1b3-8d58f3dbdfc7",
  "wait_url": "https://aisenseapi.com/services/v1/inbox/a85d0bee-f8f7-4be1-a1b3-8d58f3dbdfc7/wait/25",
  "expire_timestamp": 1800086400
}

Two identifiers come back, and they are not interchangeable. The slug is the seven characters inside the address. It is public by construction: it travels in mail headers, bounces and sender logs. Knowing it lets anyone send mail to the inbox. It never lets anyone read the inbox, and it never appears in a URL. The inbox_id is a UUID and the only credential that reads. Anyone holding it reads the mail, and it is returned once, at creation. Guessing the address does not read the inbox. A wrong inbox_id and a missing inbox both answer 404, never 403, so the two are indistinguishable.

Read the mail, or wait up to 25 seconds for it:

curl https://aisenseapi.com/services/v1/inbox/{inbox_id}
curl https://aisenseapi.com/services/v1/inbox/{inbox_id}/wait/25

{
  "ok": true,
  "slug": "ztjqt7n",
  "address": "aisense+ztjqt7n@aisenseapi.com",
  "received": 1,
  "truncated": false,
  "messages": [
    {
      "from": "noreply@example.com",
      "subject": "Your verification code",
      "date": "2027-01-15T08:00:00Z",
      "text": "Your code is 481516. Confirm at https://example.com/confirm/abc",
      "codes": [ "481516" ],
      "links": [ "https://example.com/confirm/abc" ]
    }
  ],
  "created_at_timestamp": 1800000000,
  "expire_timestamp": 1800086400
}

The read response does not contain inbox_id. The credential is never echoed back. The wait form adds waited_seconds and wait_reason to the same object. A value above 25 is clamped to 25, the same as every other wait route.

codes are standalone 4 to 8 digit numbers. links are public http(s) links only; private-IP and localhost links are dropped. date is the time the service received the message, not the sender's Date header, because that header is sender controlled.

truncated says a message was refused, whether the inbox hit the message count or the total size. A full inbox refuses new mail rather than evicting old mail, so without the flag an agent waiting for a code would see a full inbox, no code and no reason. The wait watches the flag as well as the count, so a refusal ends it instead of leaving the caller to time out.

Attachments, raw MIME, arbitrary headers, scripts, styles, private-IP links and localhost links are stripped before storage. Only the sender address, subject, received time, cleaned text, codes and public links are kept.

Limits: 20 messages per inbox, 64 KiB of cleaned text per message, 256 KiB per inbox in total, 50 inboxes per client per UTC day and 5000 active inboxes service wide. The 24-hour lifetime is fixed and cannot be extended.

MCP clients use create_agent_inbox and read_agent_inbox, whose wait watches truncated as well and returns as soon as the cap refuses a message. A2A clients name the agent-inbox skill, which creates the inbox and returns its address and URLs; reading the mail stays on REST or MCP.

---

Storage - ephemeral key-value store for pipelines

Post any JSON, text, or file. Get back a UUID. Retrieve it from anywhere - another machine, a different agent call, a downstream pipeline step.

The body is stored verbatim. Whatever you send is exactly what comes back; no wrapper is added or removed.

curl -X POST https://aisenseapi.com/services/v1/storage \
  -H "Content-Type: application/json" \
  -d '{"result": 42, "status": "complete"}'
# -> { "storage_id": "550e8400-e29b-41d4-a716-446655440000",
#      "storage_url": "https://aisenseapi.com/services/v1/storage/550e8400-e29b-41d4-a716-446655440000",
#      "sha256_hash": "...", "bytes": 36, "expire_timestamp": 1738457158 }

curl https://aisenseapi.com/services/v1/storage/550e8400-e29b-41d4-a716-446655440000
# -> {"result": 42, "status": "complete"}

Expires after 24 hours. Executable files (Windows, Linux and Mac programs, judged on their first bytes) are refused with 415. Each IP may store 80 MB per day; past that a POST answers 429. A stored file is returned inline only as an image, audio, video or PDF; anything else, SVG included, comes back as a download.

---

URL Shortener

curl "https://aisenseapi.com/services/v1/url_shortener/https://example.com/very/long/path"
# -> { "short_url": "https://307.fi/KtNshX2B", "expire_timestamp": 1786959715 }

Expires after 24 hours.

---

IP Reverse Lookup

curl https://aisenseapi.com/services/v1/ip_reverse_lookup/8.8.8.8

{
  "ip": "8.8.8.8",
  "country": "United States",
  "city": null,
  "location": { "lat": "37.751000", "lng": "-97.822000" },
  "place": null,
  "timezone": "America/Chicago"
}

city and place are frequently null, and the coordinates fall back to the country centroid when the city is unknown. Also available: resolve a domain to its IP.

curl https://aisenseapi.com/services/v1/domain_ip_lookup/example.com
# -> { "domain": "example.com", "ip": "104.20.23.154" }

---

Standard utilities

Hashing - MD5, SHA1, SHA256, SHA512, CRC32

Accepts JSON, plain text (Content-Type: text/plain), or a file upload. Each returns a key named after the algorithm, not hash.

curl -X POST https://aisenseapi.com/services/v1/sha256_hash \
  -H "Content-Type: application/json" -d '{"data": "Hello"}'
# -> { "sha256_hash": "185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969" }

md5_hash | sha1_hash | sha256_hash | sha512_hash | crc32_checksum | whirlpool_hash | sha3_256_hash | sha3_512_hash | blake2b_hash | blake3_hash

crc32_checksum returns an integer, not a hex string.

Password hashes, slow and salted, for test data, 200 operations per IP per day: argon2id_hash | bcrypt_hash | scrypt_hash, verified with password_verify, which reads the algorithm and the cost from the string.

---

Encoding - Base64, Base58, Base32, Hex, base64url, URL, HTML, JWT, QR Code

# Encode
curl -X POST https://aisenseapi.com/services/v1/base64_encode \
  -H "Content-Type: application/json" -d '{"data": "Hello world"}'
# -> { "base64_encoded_data": "SGVsbG8gd29ybGQ=" }

# Decode - returns the raw bytes, not JSON
curl -X POST https://aisenseapi.com/services/v1/base64_decode \
  -H "Content-Type: application/json" -d '{"data": "SGVsbG8gd29ybGQ="}'
# -> Hello world

# ...unless you ask for JSON
curl -X POST https://aisenseapi.com/services/v1/base64_decode \
  -H "Content-Type: application/json" -H "Accept: application/json" \
  -d '{"data": "eyJrZXkiOiJ2YWx1ZSJ9"}'
# -> { "type": "json", "decoded_data": { "key": "value" } }

The five byte decoders (base64_decode, base58_decode, base32_decode, hex_decode, base64url_decode) answer with application/octet-stream unless you send Accept: application/json. This is the one place the API is not JSON. base64_decode, hex_decode and base64url_decode also answer text/plain and refuse an Accept they cannot serve with 406; the other two give the bytes for anything but JSON.

curl -X POST https://aisenseapi.com/services/v1/hex_encode \
  -H "Content-Type: application/json" -d '{"data": "hello"}'
# -> { "hex_encoded_data": "68656c6c6f" }

curl -X POST https://aisenseapi.com/services/v1/base64url_encode \
  -H "Content-Type: application/json" -d '{"data": "hello?"}'
# -> { "base64url_encoded_data": "aGVsbG8_" }   (- and _, no padding, as in a JWT)

curl -X POST https://aisenseapi.com/services/v1/url_encode \
  -H "Content-Type: application/json" -d '{"data": "a b/c?é"}'
# -> { "url_encoded_data": "a%20b%2Fc%3F%C3%A9" }

curl -X POST https://aisenseapi.com/services/v1/html_encode \
  -H "Content-Type: application/json" -d '{"data": "<b>Tom & Jerry</b>"}'
# -> { "html_encoded_data": "&lt;b&gt;Tom &amp; Jerry&lt;/b&gt;" }

url_decode and html_decode answer JSON, url_decoded_data and html_decoded_data, since their result is text. url_decode leaves a + as a +.

HTML and Markdown. html_to_markdown turns a page or any HTML into CommonMark and answers markdown and the page title, without scripts, styles or forms. markdown_to_html answers html that is safe to put in a page: raw HTML in the Markdown is shown as text, and a link with an unsafe scheme as its text. Both take the JSON data string or the raw body.

curl -X POST https://aisenseapi.com/services/v1/html_to_markdown \
  -H "Content-Type: application/json" -d '{"data": "<h1>Hi</h1><p>A <b>bold</b> word</p>"}'
# -> { "markdown": "# Hi\n\nA **bold** word", "title": null }

curl -X POST https://aisenseapi.com/services/v1/markdown_to_html \
  -H "Content-Type: application/json" -d '{"data": "**Bold** <b>raw</b>"}'
# -> { "html": "<p><strong>Bold</strong> &lt;b&gt;raw&lt;/b&gt;</p>" }

JWT - data takes the claims as a JSON object, or as a string containing JSON. Both forms produce the same token.

curl -X POST https://aisenseapi.com/services/v1/jwt_encode \
  -H "Content-Type: application/json" \
  -d '{"data": {"user": "alice"}, "secret": "my-secret-key"}'
# -> { "jwt": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9..." }

jwt_decode returns decoded_payload.

QR - the request field is payload, with data accepted as an alias.

curl -X POST https://aisenseapi.com/services/v1/qrcode_encode \
  -H "Content-Type: application/json" -d '{"payload": "https://example.com"}'
# -> { "qrcode_image": "iVBORw0KGgoAAAANSUhEUgAA...", "image_type": "png" }

qrcode_decode takes the same payload field (or a file upload) and returns qrcode_content. The image is a PNG, JPEG, GIF or WebP of at most 10 MB as a file upload. A JSON body is at most 256 KiB, so through payload the image can be about 190 KB.

---

Random - UUID, GUID, number, color, password

curl https://aisenseapi.com/services/v1/uuid            # { "uuid": "..." }
curl https://aisenseapi.com/services/v1/guid            # { "guid": "..." }
curl https://aisenseapi.com/services/v1/random_color    # { "random_color": "#9b6bbf" }
curl https://aisenseapi.com/services/v1/random_number/1/100
# -> { "random_number": 73, "range": { "from": 1, "to": 100 } }
curl https://aisenseapi.com/services/v1/password/16
# -> { "password": "jFehS]AKGx9wl[jp", "password_length": 16 }

A single argument to random_number is the upper bound, with the lower bound fixed at 1.

---

Time - Datetime, Timestamp, Timezones

curl https://aisenseapi.com/services/v1/datetime            # UTC
curl https://aisenseapi.com/services/v1/datetime/+0200      # with offset
curl https://aisenseapi.com/services/v1/datetime/europe/oslo  # a zone by name, summer time included
curl https://aisenseapi.com/services/v1/ip_datetime         # the same, where your address is
curl https://aisenseapi.com/services/v1/timestamp
curl https://aisenseapi.com/services/v1/microtimestamp
curl https://aisenseapi.com/services/v1/timezones
curl https://aisenseapi.com/services/v1/swatchinternettime

The offset is four digits with an optional sign - +0200, -0530, 0100 - or the same with a colon, +02:00. An hour-only value like 1 is not a valid route. A zone name such as europe/oslo, in any case, follows summer time, which a fixed offset does not. Its answer has the offset in force, the standard offset, whether summer time is on and when it starts and ends, and the day and week numbers. /ip_datetime[/{ip}] answers the same for the zone an address is in, the caller's own without one.

A client of worldtimeapi.org, which reset every connection we made on 3 October 2026, finds its answers here: /api/timezone/{zone} is /datetime/{zone}, /api/ip[/{address}] is /ip_datetime[/{ip}] and /api/timezone is /timezones, all JSON over HTTPS. The translation table has the details.

/timezones returns objects, not strings: {"timezones": [{"timezone": "Europe/Oslo", "offset": "+0200"}, ...]}.

---

Web utilities - Ping, Health, Client IP, User Agent

curl https://aisenseapi.com/services/v1/ping        # { "ping": "pong" }
curl https://aisenseapi.com/services/v1/health      # { "status": "ok", "microtimestamp": ... }
curl https://aisenseapi.com/services/v1/client_ip   # { "ip": "203.0.113.42" }
curl https://aisenseapi.com/services/v1/user_agent  # { "user_agent": "curl/8.5.0" }

---

Crypto - Wallet generation and balance lookup

curl https://aisenseapi.com/services/v1/solana/generate_new_wallet
curl https://aisenseapi.com/services/v1/bitcoin/generate_new_wallet
curl https://aisenseapi.com/services/v1/ethereum/generate_new_wallet

curl https://aisenseapi.com/services/v1/solana/balance/{address}
curl https://aisenseapi.com/services/v1/bitcoin/balance/{address}
curl https://aisenseapi.com/services/v1/ethereum/balance/{address}

All three generators return public_address (Bitcoin also returns private_key_wif). Ethereum balances come back as strings - {"wallet": "0x...", "balance_eth": "6.634527787345637061", "balance_wei": "6634527787345637061"}

• because Wei routinely exceeds 2^53, the largest integer a JSON number survives in a JavaScript client.

Wallet generation is for development and testing only. A key produced by a public HTTP endpoint has crossed a network you do not control. Never fund one.

---

The bundled JavaScript and Python clients wrap Agent Queue with eight methods each, one per MCP tool; the raw HTTP examples above show the same calls.

Quick start by language

curl

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

Python - zero dependencies, standard library only.

from aisense_api import AISenseAPI
api = AISenseAPI()

print(api.get_uuid()["uuid"])
print(api.hash_sha256("Hello")["sha256_hash"])
print(api.ip_reverse_lookup("8.8.8.8")["country"])

JavaScript - Node 18+ or any modern browser, native fetch.

import { AISenseAPI } from './aisense-api.js'
const api = new AISenseAPI()

console.log((await api.getUUID()).uuid)
console.log((await api.hashSHA256('Hello')).sha256_hash)
console.log((await api.ipReverseLookup('8.8.8.8')).country)

Both clients return the parsed response, and every method's docstring names the exact response key. They also raise a clear error when a path does not exist, rather than letting the debug echo surface as a JSON parse failure. They cover every endpoint in API.md, which tools/check-sdk-coverage.py checks along with openai-tools.json. The image methods upload the file as multipart/form-data, and the failure simulator returns what the API sent instead of raising.

LLM function calling (OpenAI, Gemini, Mistral, ...)

import json
from openai import OpenAI

with open("openai-tools.json") as f:
    tools = json.load(f)

client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4o",
    tools=tools,
    messages=[{"role": "user", "content": "Generate a UUID and hash the word Hello with SHA256"}]
)

Claude - SKILL.md is included. Add it to Claude's context and it will use these APIs as tools automatically.

---

What's in the repo

test.sh asserts on response bodies as well as status codes. Bodies are the part that matters most: a status-code-only suite passes an endpoint that answers 200 with the wrong response key.

---

Endpoint summary

All paths are relative to https://aisenseapi.com/services/v1/

Documentation truncated — see the full README on GitHub.