Skip to main content
Glama

AgentMart

by ai.ciphyr.agentmart
OverviewDiscussionsAdmin

Buy with the balance

buy
Destructive

Buy an item from your balance. Utilities start immediately; kits return a single-use download link. Pass instance_id to renew a utility you own. Above what is left of today's spending limit, the order is not refused: it answers status pending_approval (HTTP 202) with its order_id, nothing is taken, and your owner gets one email to approve it within 24 hours. Then get_order shows paid (with delivery), declined, expired, cancelled or approval_failed. Retry with the same idempotency_key: it returns the same order, never a second one. Human services (shelf human, done by AgentMart's own team, checked by a second person): quote_human_service first (free), then pass brief in the service's schema (get_item: details.brief_schema) and max_price_cents, and any login only as secret. The answer's delivery holds job_id: then get_job. A website test first waits for your proof that each site is yours (delivery.verification, then verify_job_sites).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemYesItem slug from search_catalog
briefNoHuman services only: what our team needs, in the service's schema (get_item shows details.brief_schema).
secretNoHuman services only: a test login or access key. Write-only: encrypted, shown only to the one team member doing the job, deleted when it closes. Never put it in brief.
instance_idNoTo renew: the utility instance id you own. Leave out for a new one.
passport_tokenNoYour amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in.
idempotency_keyNoReuse to retry safely without paying twice
max_price_centsNoThe most this order may cost, in US cents: a higher price (as we count it) is refused and nothing is taken.
inbox_instance_idNoOne of your owner's webhook inboxes: what happens to this order (approved, declined, expired) and its job is written there.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / brief
      Added value: +{
+  "additionalProperties": {},
+  "description": "Human services only: what our team needs, in the service's schema (get_item shows details.brief_schema).",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • addedInput schema / properties / inbox_instance_id
      Added value: +{
+  "description": "One of your owner's webhook inboxes: what happens to this order (approved, declined, expired) and its job is written there.",
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / max_price_cents
      Added value: +{
+  "description": "The most this order may cost, in US cents: a higher price (as we count it) is refused and nothing is taken.",
+  "maximum": 10000000,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / secret
      Added value: +{
+  "description": "Human services only: a test login or access key. Write-only: encrypted, shown only to the one team member doing the job, deleted when it closes. Never put it in brief.",
+  "maxLength": 2000,
+  "minLength": 1,
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / instance_id / description
      Added value: +"To renew: the utility instance id you own. Leave out for a new one."
    • changedInput schema / properties / passport_token / description
      Previous value: -"Leave it out when your MCP app signed in to AgentMart (it is refused then). Otherwise your passport bearer token (amp_...) or session token (amp_s_...), only if your client cannot send it as an Authorization header. A token here sits in your context, so it never authorizes sensitive actions."New value: +"Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses that orders above the remaining daily limit are not refused but parked as status pending_approval (HTTP 202) with an order_id, that nothing is charged, that the owner gets one approval email valid 24 hours, and enumerates the terminal outcomes (paid, declined, expired, cancelled, approval_failed). It also explains secret handling (write-only, encrypted, shown to one team member, deleted on close) and the quote-first flow for human services.

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

Conciseness4/5

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

Front-loaded with the core purchase action and every sentence carries operational content, so the length is justified for an 8-parameter multi-flow tool. It is delivered as one dense run-on block, though, with the human-service and website-test flows appended rather than separated, which slightly hurts scannability.

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?

With no output schema, the description carries the return burden and does so: it explains the pending_approval/HTTP 202 path, the order_id, the final statuses, that delivery holds job_id for get_job, and that approval results land in the inbox_instance_id webhook. Combined with the human-service and verification sub-flows, an agent has everything needed to call and follow up correctly.

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 baseline is 3, but the description adds real meaning beyond the schema: instance_id means renewal of a utility you own, max_price_cents above-limit behavior (refused, nothing taken), secret must never be placed in brief, and idempotency_key is the retry-safety mechanism. This compensates meaningfully rather than repeating field docs.

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?

States a specific verb and resource (buy an item from your balance) and immediately scopes the two modes: utilities start at once, kits return a download link. An agent can distinguish this from top_up, quote_human_service and search_catalog without opening any schema.

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

Usage Guidelines5/5

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

Explicit routing: pass instance_id to renew vs omit for a new utility; for human services call quote_human_service first, then pass brief/max_price_cents; for website tests expect delivery.verification and verify_job_sites. It also names the follow-up tools (get_order, get_job) and the idempotency retry rule, leaving nothing to inference.

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

All AgentMart toolsInspect
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