Skip to main content
Glama

AgentMart

by ai.ciphyr.agentmart
OverviewDiscussionsAdmin

Set the form digest email and the site name

set_form_digest
DestructiveIdempotent

Change your form inbox's settings: the daily digest email to your owner (digest on or off: at most one email a day for all their forms, only while new entries arrive) and the site name its thank-you page shows visitors (site_name, 1 to 60 characters, null clears it). Send either or both. The answer says whether email can reach your owner right now (email: ready, unconfirmed, no_address, not_configured or owner_opted_out; unconfirmed means your owner gets one confirmation email, only once until they confirm, and digests start after they confirm) and when digests go out (digest_schedule).

Input Schema

NameRequiredDescriptionDefault
digestNotrue: daily digest email on; false: off.
site_nameNoThe name of your site, shown as plain text on the thank-you page after a visitor sends the form. null clears it.
instance_idYesUtility instance id from buy or list_utilities.
passport_tokenNoYour amp_ token, only if you have no app sign-in and cannot send a header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "digest": true,
+    "instance_id": "frm_exampleexampleexample2",
+    "site_name": "Example Site"
+  }
+]
    • 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."
  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. Changed2 schema fields changed
    • addedInput schema / properties / site_name
      Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 240,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The name of your site, shown as plain text on the thank-you page after a visitor sends the form. null clears it."
+}
    • changedInput schema / required
      Previous value: -[
-  "instance_id",
-  "digest"
-]New value: +[
+  "instance_id"
+]
  4. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / digest / description
      Added value: +"true: daily digest email on; false: off."
    • 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."
  5. First observed

TDQS

A4.1/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: daily digest cadence, that only new entries trigger emails, that site_name null clears the value, and detailed return statuses for email deliverability and digest scheduling. It matches the mutation/destructive 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.

Conciseness4/5

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

The description is front-loaded with the purpose and the details generally earn their place, including return-value context since no output schema exists. It is dense and uses nested parentheticals, which slightly reduces readability.

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?

Because there is no output schema, the description usefully explains the return shape and email status meanings. It omits some auth/parameter details covered by the schema and does not describe error behavior, but it is otherwise complete for this operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 introduces a conflicting constraint: it says site_name is 1 to 60 characters while the schema allows maxLength 240. It also does not mention passport_token, though the schema documents it.

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 uses a specific verb ('Change') and clearly names the resource and the two settings affected: the daily digest email and the site name shown on the thank-you page. This is distinguishable from sibling tools despite not naming a direct alternative.

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?

It clearly indicates the context for use ('Change your form inbox's settings') and clarifies that either or both settings may be sent. It does not explicitly name alternatives or when not to use it, but the usage context is clear.

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