Skip to main content
Glama

Emboss

by io.github.edwinorange
OverviewDiscussionsAdmin

Commit a proposal and produce the PDF

commit_proposal

Write or confirm the answers, render the form with text that fits, check it, and return the PDF with a report and a receipt, or one submission package. Give the proposal_id from prepare_form; confirm is a list of field ids whose proposed value is accepted as it is (the ids get_proposal lists under confirmations); plus any values the agent decided for fields still open (field_id, value, and an optional note), and a policy (safe or strict) to override the proposal's own. Set package to true to also receive one submission package: the filled form, the attachments added to this proposal in the order the form asks for them, and the receipt embedded in the file; that is billed as one package. Returns a job_id; poll get_job about every 20 seconds for the download link, report, receipt and, when asked for, package_url. Free within the proposal's already-billed prepare, up to 10 commits per proposal. Checkboxes take yes or no; yes ticks that box. In a Yes/No pair, say yes to the box you want; two yeses in one pair are refused. Pass dry_run=true to rehearse this call without doing it: nothing is stored, charged or sent, and no AI is used. The answer says whether the real call would succeed or be refused, what it would cost, and what a rehearsal cannot check.

Input Schema

NameRequiredDescriptionDefault
policyNo
valuesNo
confirmNo
dry_runNo
packageNo
proposal_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "confirm": [
-      3
-    ],
-    "package": false,
-    "proposal_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
-    "values": [
-      {
-        "field_id": 5,
-        "value": "Grace Hopper"
-      }
-    ]
-  }
-]New value: +[
+  {
+    "confirm": [
+      3
+    ],
+    "package": false,
+    "proposal_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
+    "values": [
+      {
+        "field_id": 5,
+        "value": "Grace Hopper"
+      }
+    ]
+  },
+  {
+    "confirm": [
+      3
+    ],
+    "dry_run": true,
+    "package": false,
+    "proposal_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
+    "values": [
+      {
+        "field_id": 5,
+        "value": "Grace Hopper"
+      }
+    ]
+  }
+]
    • addedInput schema / properties / dry_run
      Added value: +{
+  "default": false,
+  "title": "Dry Run",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "confirm": [
+      3
+    ],
+    "package": false,
+    "proposal_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
+    "values": [
+      {
+        "field_id": 5,
+        "value": "Grace Hopper"
+      }
+    ]
+  }
+]
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses billing behavior, the async job model ('Returns a job_id; poll get_job about every 20 seconds'), validation rules ('two yeses in one pair are refused'), checkbox semantics, and exactly what dry_run does and cannot check. This is rich behavioral context an agent could not infer from annotations.

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?

It is front-loaded with the action and result, which is good, but it is a single dense paragraph mixing workflow, validation rules, billing, and rehearsal semantics. All sentences carry information, yet the density makes it harder to scan than a short structured list.

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?

For a six-parameter mutation with an output schema, the description covers prerequisites, side effects, cost, async polling, edge-case validation, and dry-run limits. Nothing an agent needs in order to call it correctly is missing; return-value detail is appropriately left to the output schema.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the full burden, and it does: proposal_id source, confirm as field ids 'get_proposal lists under confirmations', values shape (field_id, value, optional note), policy values (safe or strict) and its override semantics, package meaning and billing, and dry_run behavior. Every one of the six parameters is given meaning beyond its bare name.

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 names specific verbs and resources: write/confirm answers, render the form, check it, return the PDF with report and receipt or a submission package. It clearly distinguishes this commit step from prepare_form (the source of proposal_id) and from composition/fill siblings, so an agent can tell what it produces without opening the schema.

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 states the prerequisite ('Give the proposal_id from prepare_form'), the free-tier boundary ('Free within the proposal's already-billed prepare, up to 10 commits per proposal'), and when to use dry_run. It does not explicitly name an alternative sibling to use instead in any scenario, but the workflow position is unambiguous.

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

All Emboss 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