Skip to main content
Glama

AgentMart

by ai.ciphyr.agentmart
OverviewDiscussionsAdmin

Quote a human service (free)

quote_human_service
Read-only

What a human service order would cost, free: our count ("70 words, English to Turkish", "40 lines of code"), price_cents, the promise, daily_limit (whether it fits what is left of your owner's limit today, or needs their approval by email) and a signed quote (quote_jws, valid 24 hours). Send the whole brief, or text (per-word services, or a code review's code) or item_count (labels). Any other item with item alone: its price for your owner (the first blueprint quotes 0); the email check with item_count, the number of different entries in your list. Nothing is taken, and the brief is not kept (for an agent with an owner, only a keyed note of each address name we looked up, used for 5 minutes and deleted by our daily cleanup); the order counts the same way again, so pass max_price_cents to buy.

Input Schema

NameRequiredDescriptionDefault
itemYesA human service slug (search_catalog with shelf human).
textNoPer-word services: exactly the text you will order.
briefNoThe whole brief, exactly as you will order it.
languageNoProofreading quoted by text: the text's language, a tag such as en (our team's languages only).
item_countNoLabels: how many items. The email check: how many different entries your list has.
passport_tokenNoYour amp_ token, only if you have no app sign-in and cannot send a header.
source_languageNoTranslation quoted by text: the text's language, a tag such as en (our team's languages only).
target_languageNoTranslation quoted by text: the language to translate into, a tag such as tr (our team's languages only).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "item": "human-proofreading",
+    "language": "en",
+    "text": "This is a short example text."
+  }
+]
    • addedInput schema / properties / language / description
      Added value: +"Proofreading quoted by text: the text's language, a tag such as en (our team's languages only)."
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."New value: +"Your amp_ token, only if you have no app sign-in and cannot send a header."
    • addedInput schema / properties / source_language / description
      Added value: +"Translation quoted by text: the text's language, a tag such as en (our team's languages only)."
    • addedInput schema / properties / target_language / description
      Added value: +"Translation quoted by text: the language to translate into, a tag such as tr (our team's languages only)."
  2. Changed4 schema fields changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / passport_token / description
      Previous value: -"Your amp_ token, only if your client cannot send it as an Authorization header; leave it out when your MCP app signed in."New value: +"Your amp_ token, only if your app has no sign-in and cannot send it as an Authorization header."
    • addedInput schema / properties / passport_token / maxLength
      Added value: +200
    • removedInput schema / properties / passport_token / pattern
      Removed value: -"^amp_(?:s_)?[A-Za-z0-9_-]{43}$"
  3. Changed1 schema field changed
    • changedInput schema / properties / item_count / description
      Previous value: -"Labels: how many items."New value: +"Labels: how many items. The email check: how many different entries your list has."
  4. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context: the quote is free, nothing is taken, the brief is not kept, address-name lookups are keyed and deleted after cleanup, and the signed quote is valid for 24 hours. It also discloses that daily_limit may require owner approval by email. These details go well beyond the annotations without contradicting them.

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 front-loads the main purpose, but it is a dense, run-on paragraph overloaded with parenthetical examples and nested clauses. Several phrases are awkward and could be shortened without losing meaning. It is informative but poorly structured and not concise.

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?

There is no output schema, so the description must explain return values; it does so by naming count, price_cents, promise, daily_limit, and the signed quote. It also covers privacy behavior and quote validity. Given the annotations and complete parameter schema coverage, this is largely complete, though the output shape is still described informally rather than precisely.

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, but the description adds useful combination semantics: whole brief versus text for per-word services versus item_count for labels and email checks. It also notes that item alone returns the owner's price for other services. The reference to max_price_cents is for the sibling buy tool and is slightly muddying, but the parameter guidance still adds value.

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?

The description clearly establishes that this tool returns a free quote for a human service order and lists the quote components: word/line count, price_cents, promise, daily_limit, and signed quote. It also distinguishes the quote from the eventual purchase by noting that the order counts the same way again and that max_price_cents should be passed to buy. The wording is convoluted, but the core verb and resource are identifiable.

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

Usage Guidelines3/5

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

The description explains input patterns such as sending the whole brief, text for per-word services, or item_count for labels and email checks. It does not explicitly frame when to use this tool instead of buy or search_catalog, though the buy reference implies it is a pre-purchase quote. Usage is implied rather than clearly directed.

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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources