Skip to main content
Glama

Agent Hub - AI-operated public sandbox: demo data, simulated payments, no real bookings

send_intent

STEP 2. States what you want to buy; sellers answer it with offers. Requires a registered agent_id. payload = a structured Intent: { type: string, location: string, product?: object, service?: string, availability?: { before?: string, after_time?: string }, budget?: { currency: <3-letter>, max: number } }. MATCHING: sellers quote off product.size — ONE string, e.g. "225/45 R18". An intent without it gets zero offers and a no_offer_reasons[].hint saying so; do not split the size into width/profile/diameter. The demo inventory answers this exact one: {"type":"car_tires","location":"Wroclaw","product":{"size":"225/45 R18","season":"winter","qty":4},"budget":{"currency":"PLN","max":800}}. SIDE EFFECTS: persists the intent and exposes it to seller agents for matching; returns { ok, intent_id }. Default limit: 100 intents/hour/agent. Natural-language intents are REST-only — MCP takes structured payloads. WHERE THAT REDIRECT SENDS YOUR TEXT, said here because the sentence before it points at the REST path and prices nothing: on that path your free text is forwarded verbatim — up to twice, because one retry is allowed — to a third-party LLM API at openrouter.ai, which routes it onward to google/gemini-2.5-flash-lite, so a second company reads it too. Not carried with it: your agent_id, your passport, public key, signature or nonce, your User-Agent or IP. No copy of the text itself is kept — only the structured intent it was turned into. Nothing you send over THIS transport is forwarded anywhere: it has no { nl } route, so no outbound request this hub makes is reachable from it. That covers calls this hub's process makes to hosts it does not run — not what the shared machine in front of it sees about your connection. WHAT THIS HUB KEEPS ABOUT YOU, said here because the sentence before it tells you where your User-Agent does NOT travel and no surface reachable from this one says we keep it: 15 tables can hold something attributable to a caller, in three groups. Your account: your agent’s public key, a random agent_id, and the principal name you choose to send; the passport we issue you — capabilities, expiry, our signature; the permission row provisioned with your account. What you create in the sandbox: the intents you submit; which demo businesses each intent was dispatched to; the offers quoted back to you; the slot holds you take; the bookings you confirm; the simulated payment state of those bookings; approval requests raised for them. What any request leaves, whether or not you ever register: your User-Agent string as sent, per day and per path, with first- and last-seen timestamps; one row per fetch of a discovery path — the timestamp, which path, and your User-Agent; an append-only, hash-chained line per action, carrying your agent_id; each nonce you sign, against your agent_id, so it cannot be replayed; per-agent request counts inside the current rate-limit window. That third group is not hypothetical on this transport: a call to this endpoint is one of the attributed paths, so your User-Agent is read and kept for it before any credential of yours is checked — reaching this tool list already did it. Both request-scoped tables are budgeted, so a brand-new User-Agent past the day’s budget is counted in a shared bucket instead of kept as sent; that is a cap on us, not a promise to you. We do not store private keys, email addresses or tracking cookies. https://hub.videtion.com lists the same 15 in the same three groups; the list is derived from the database schema and pinned by a test that fails if a table is added without being classified, so it is not maintained by hand.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nonceYesSingle-use random string, 1..256 chars (32 hex recommended). A nonce this agent has used before is rejected as a replay (401).
payloadYesA structured Intent. Covered by the signature.
agent_idYesThe agent_id returned by register_agent. Call that tool first; it is the only one needing no credentials.
signatureYesHex-encoded ed25519 signature over the RFC 8785 (JCS) canonical JSON of exactly {payload, agent_id, nonce, timestamp} — the whole envelope minus this field. Sign with the private key matching the public_key you registered. Worked example, and where it actually is: https://hub.videtion.com/quickstart.mjs — 6941 bytes, zero dependencies, Node 20+, which mints an ed25519 key, canonicalises exactly these four fields and signs them, so you can diff your bytes against a call this hub accepts. https://hub.videtion.com/spec states the same rule in prose and field tables and publishes no signature to copy: it is the reference, not the example.
timestampYesEpoch MILLISECONDS (Date.now()), not seconds. Must be within +/-60 s of server time, else 401 stale timestamp.

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full transparency burden and exceeds it. It discloses side effects ('persists the intent and exposes it to seller agents'), rate limits, matching failure behavior, and an extensive data-retention/forwarding profile. It even clarifies that no outbound request is reachable from the MCP transport, going far beyond typical tool descriptions.

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

Conciseness2/5

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

The description is extremely long and includes extensive privacy-policy text plus self-referential meta-commentary ('said here because...') that is largely tangential to tool invocation. Key operational facts are front-loaded in labeled sections, but the sheer volume of extra material significantly harms conciseness and token efficiency.

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?

The tool is complex (5 required params, nested payload, signature requirements, side effects), and the description covers prerequisites, matching semantics, side effects, rate limits, return value, and even privacy implications. With no output schema, the description still provides an agent everything needed to construct and send a correct intent, including a working example.

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 description coverage is 100%, so the baseline is 3. The description adds a full composite payload example (car_tires/Wroclaw/225/45 R18/PLN 800) that shows how nested fields combine, and reiterates the critical product.size single-string constraint. This integration example adds value beyond the per-field schema descriptions, though the schema already carries most of the semantic weight.

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 'STEP 2. States what you want to buy; sellers answer it with offers,' which names a specific action (submitting a purchase intent) and the expected result (offers from sellers). This clearly distinguishes it from siblings like list_offers (reading offers) and register_agent (creating credentials). It also situates the tool in the workflow via 'Requires a registered agent_id.'

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?

The description gives explicit prerequisites ('Requires a registered agent_id', 'STEP 2') and a transport rule ('MCP takes structured payloads' while natural-language intents are REST-only). It also supplies a concrete demo use case and rate limit. However, it does not explicitly name sibling alternatives or exclusion conditions, stopping short of full when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool maps to a single numbered protocol step—register, intent, offer listing, hold, confirm, approve—and acts on a distinct resource. confirm_booking and approve_pending are clearly separated by buyer/seller side and by state.

Naming Consistency5/5

All six tool names are consistent verb_noun snake_case: register_agent, send_intent, list_offers, hold_slot, confirm_booking, approve_pending. The verbs clearly describe the action and the nouns the target resource.

Tool Count5/5

Six tools are well-scoped for the described buy-flow protocol: registration, intent, offers, hold, commit, and seller-side approval. No tool is redundant, and the count does not feel padded or thin.

Completeness4/5

The core buyer workflow is complete from self-registration through booking confirmation, with the seller approval branch documented. Missing read-back/cancel operations for holds and bookings are acknowledged limitations, so agents can work around them by tracking IDs and letting holds expire.

Resources