Skip to main content
Glama
YosefHayim

ebay-mcp

by YosefHayim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ebay_create_signing_key

Create an ED25519 or RSA signing keypair for eBay API digital signatures; save the private key immediately and configure the returned JWE/private key before restarting the server.

Instructions

Create a new signing keypair for API digital signatures. Supports ED25519 (recommended) or RSA ciphers. IMPORTANT: Save the private key immediately as eBay does not store it. To sign the calls eBay requires signatures on for EU/UK sellers (Finances API, issueRefund), set EBAY_SIGNING_KEY_JWE to the returned jwe and EBAY_SIGNING_PRIVATE_KEY to the returned privateKey, then restart the server.

Input Schema

NameRequiredDescriptionDefault
requestNoOptional signing-key request body

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.14.1
    • addedInput schema / properties / request
      Added value: +{
+  "additionalProperties": false,
+  "description": "Optional signing-key request body",
+  "properties": {
+    "signingKeyCipher": {
+      "description": "Cipher for the generated keypair, e.g. ED25519 or RSA",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
    • removedInput schema / properties / signingKeyCipher
      Removed value: -{
-  "description": "Cipher to use for keypair: ED25519 (recommended, shorter keys) or RSA (legacy support)",
-  "enum": [
-    "ED25519",
-    "RSA"
-  ],
-  "type": "string"
-}
  2. First observedv1.8.10

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the critical trait that eBay does not store the private key and it must be saved immediately, and it explains the post-creation configuration (EBAY_SIGNING_KEY_JWE, EBAY_SIGNING_PRIVATE_KEY, server restart). It omits any mention of key-count limits or the auth/permission requirements for creating a key.

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

Conciseness5/5

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

Four sentences, each carrying distinct value: what it creates, the cipher options, the irreversible private-key handling, and the env-var wiring. The critical warning is front-loaded with "IMPORTANT" rather than buried.

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?

Given no output schema, the description helpfully names the returned fields (jwe, privateKey) that must be persisted, and it explains the end-to-end setup. It stops short of stating whether multiple keys are allowed or what happens on re-invocation, which an agent managing credentials would want to know.

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 baseline is 3, but the description adds meaning beyond the schema by marking ED25519 as recommended — the schema only says "e.g. ED25519 or RSA" without a preference. The nested request wrapper and its optionality are left to the schema.

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 and resource ("Create a new signing keypair for API digital signatures") plus the supported ciphers, so an agent immediately knows the operation. It never names the retrieval siblings (ebay_get_signing_keys / ebay_get_signing_key), so differentiation relies on the name rather than explicit guidance.

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?

Gives real context for why an agent would call it: signing keys are needed for the calls eBay requires signatures on for EU/UK sellers, naming the Finances API and issueRefund. It gives no explicit when-not or alternative mention (e.g., reuse an existing key via ebay_get_signing_keys before creating another), 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.

Deploy Server

Other Tools