Signatoro

Save or update my signature

update_my_signature

DestructiveIdempotent

Save or change the signed-in person's own signature on Signatoro: name, title, phone, address, email, website, LinkedIn, extra link, photo, review badge, booking button, layout, color and font. With nothing saved yet, this creates the signature. Give only the fields to change; the rest keep their saved values, and "" clears a field. Company brand items (logo, company colors, the company review badge or booking button) are set by the company owner on signatoro.com: fields the company controls are left unchanged and listed in ignored, with who changes them; tell the person. A connected mailbox (Zoho Mail) gets the new signature. Returns the updated signature as HTML and text with sender, the details as fields, and counts as one signature request like get_signature; with the month used up, the change is saved and the signature held back. When nothing changed, nothing is written or counted.

Input Schema

Name	Required	Description
`font`	No	sans or serif.
`name`	No	Full name.
`color`	No	Accent color as a 6-digit hex, e.g. "#6a040f".
`email`	No	Email address.
`phone`	No	Phone number as it should read.
`title`	No	Job title.
`layout`	No	One of line, mark, portrait, stack, compact. Call list_templates to choose.
`address`	No	Address, one line as it should read.
`company`	No	Company name.
`logoUrl`	No	Only a logo uploaded on signatoro.com is accepted; "" removes the logo.
`website`	No	Website, e.g. "northwind.co".
`linkedin`	No	LinkedIn profile URL.
`photoUrl`	No	Only a photo uploaded on signatoro.com is accepted; "" removes the photo.
`reviewUrl`	No	Link to the reviews page. The badge needs it.
`bookingUrl`	No	Booking page URL. The button needs it.
`reviewCount`	No	Number of reviews, e.g. "127".
`bookingLabel`	No	Button text, e.g. "Book a call".
`extraLinkUrl`	No	URL of the extra link. Shown only with extraLinkLabel.
`reviewRating`	No	Score, e.g. "4.8". Needed for google and g2.
`extraLinkLabel`	No	Text of one extra link, e.g. "Book a demo".
`reviewPlatform`	No	Review badge platform: trustpilot, google, g2, or "" to remove the badge.
`bookingProvider`	No	Booking button provider: calendly, cal, other, or "" to remove the button.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / address

Added value: +{
+  "description": "Address, one line as it should read.",
+  "maxLength": 200,
+  "type": "string"
+}

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / email / anyOf

Previous value: -[
-  {
-    "const": "",
-    "type": "string"
-  },
-  {
-    "format": "email",
-    "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "const": "",
+    "type": "string"
+  },
+  {
+    "format": "email",
+    "maxLength": 200,
+    "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+    "type": "string"
+  }
+]

First observedOct 1, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Richly describes side effects: creation vs update, partial update semantics, clearing, ignored company-controlled fields (with explanation), mailbox sync, return format, quota counting like get_signature, held-back signature when quota exhausted, and no-op when nothing changes. Annotations mark it as destructive, which the description confirms via "" clearing.

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 dense but front-loads the core purpose, then moves through usage and behavioral details. It could be better structured with line breaks, but every sentence carries useful information.

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 22-parameter write tool with no output schema, the description covers everything an agent needs: creation/update distinction, partial update semantics, clearing, ignored fields, mailbox integration, return format, quota behavior, and no-op condition. No significant gaps.

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 baseline is 3. The description adds meaning beyond the schema by explaining that omitted fields keep saved values and that "" clears a field, which helps interpret the optional parameters.

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?

States a specific verb (save/change) and resource (signed-in person's own signature) and enumerates the fields it handles. It distinguishes personal signature from others implicitly, but does not explicitly name sibling tools like create_signature or update_member_field.

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?

Explains that with nothing saved it creates a signature, and that only provided fields change, with "" clearing a field. It also warns about company-controlled fields being ignored. No explicit when-to-use versus alternatives, but the 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 Signatoro tools Inspect

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

Need Help?