How do I use mcp-ecdsa?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-ecdsa Generate a new ECDSA key pair" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-ecdsa

by daedalus

Overview Schema Related Servers Score Discussions

Python

Remote

mcp-ecdsa

MCP server for ECDSA cryptography

PyPI Python Ruff

mcp-name: io.github.daedalus/mcp-ecdsa

Install

pip install mcp-ecdsa

Related MCP server: dpay-mcp

Usage

As MCP Server

Configure in your MCP client:

{
  "mcpServers": {
    "mcp-ecdsa": {
      "command": "mcp-ecdsa"
    }
  }
}

Python API

from mcp_ecdsa import generate_key, sign_data, verify_signature

# Generate key pair
result = await generate_key({"curve": "NIST256p"})
data = json.loads(result[0].text)

# Sign data
sign_result = await sign_data({
    "private_key": data["private_key"],
    "data": "Hello, World!"
})

# Verify signature
verify_result = await verify_signature({
    "public_key": data["public_key"],
    "signature": json.loads(sign_result[0].text)["signature"],
    "data": "Hello, World!"
})

Tools

Tool	Description
`generate_key`	Generate ECDSA key pair
`sign_data`	Sign data (with hashing)
`sign_digest`	Sign pre-hashed digest
`verify_signature`	Verify signature over data
`verify_digest_signature`	Verify signature over digest
`import_private_key`	Import from PEM/DER/base64
`import_public_key`	Import from PEM/DER/base64
`export_private_key`	Export to PEM/DER/base64/SSH
`export_public_key`	Export to PEM/DER/base64/SSH
`get_key_info`	Get key information
`recover_public_key`	Recover public keys from signature

Supported Curves

NIST192p, NIST224p, NIST256p, NIST384p, NIST521p
SECP256k1
Ed25519, Ed448

Supported Hash Functions

SHA1, SHA224, SHA256, SHA384, SHA512
SHA3-256, SHA3-384, SHA3-512

Development

git clone https://github.com/daedalus/mcp-ecdsa.git
cd mcp-ecdsa
pip install -e ".[test]"

# run tests
pytest

# format
ruff format src/ tests/

# lint
ruff check src/ tests/

# type check
mypy src/

Available Tools

11 tools

_export_private_keyC

Export a private key to various formats

ParametersJSON Schema

Name	Required	Default
`private_key`	Yes
`curve`	No	NIST256p
`format`	No	pem
`pem_format`	No	ssleay

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, so description should disclose behavior. It only says 'export to various formats' without mentioning if it's a read-only operation, potential side effects, or permission requirements.

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

Conciseness3/5

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

A single sentence is concise, but it sacrifices informative value. It could be more descriptive without being wordy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, missing schema descriptions, and an output schema, the description is incomplete. It does not address return values, format details, or usage context.

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

Parameters1/5

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

With 0% schema description coverage, the description must explain parameters. It does not elaborate on 'private_key', 'curve', 'format', or 'pem_format', leaving the agent without semantic guidance.

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 states the action 'Export' and the resource 'private key', with 'various formats' indicating flexibility. It distinguishes from sibling tools like _export_public_key by specifying the private key.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., _get_key_info) or prerequisites (e.g., key must exist). The description does not mention any context for usage.

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

_export_public_keyC

Export a public key to various formats

ParametersJSON Schema

Name	Required	Default
`public_key`	Yes
`curve`	No	NIST256p
`format`	No	pem
`point_encoding`	No	uncompressed

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided; the description only says 'export', implying a read-only operation, but lacks details on any behavioral traits, requirements, or side effects.

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

Conciseness3/5

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

One sentence is concise and front-loaded, but too brief to be fully effective. It could benefit from listing formats or parameter context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters and no annotations, the description is incomplete. It doesn't explain parameter choices or output, though an output schema exists. Significant gaps remain.

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

Parameters1/5

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

Schema coverage 0%: the description does not explain any parameter beyond 'various formats'. Parameters like curve, format, point_encoding have defaults but no description adds meaning.

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 states it exports a public key to various formats, indicating the action and resource. It distinguishes from siblings like _export_private_key, though 'various formats' is vague.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like _export_private_key or _recover_public_key. Usage is implied but not explicit.

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

_generate_keyC

Generate a new ECDSA key pair

ParametersJSON Schema

Name	Required	Description	Default
`curve`	No		NIST256p
`hashfunc`	No		sha256

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, and the description only states it generates a key pair. It does not disclose whether the key is stored in memory, any side effects, or authorization requirements, leaving the agent with incomplete behavioral context.

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?

The description is a single, concise sentence that is front-loaded with the core action and resource. It contains no unnecessary words or information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists (reducing the need to explain return values), the description lacks crucial context about parameter semantics, usage alternatives, and behavioral traits. This is insufficient for a tool that generates cryptographic keys within a suite of related operations.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description adds no explanation for the parameters 'curve' and 'hashfunc.' The defaults (NIST256p, sha256) and valid options are not clarified, so the agent receives no added meaning beyond the schema.

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 explicitly states 'Generate a new ECDSA key pair,' which is a specific verb-resource combination that clearly distinguishes it from sibling tools like _export_private_key or _import_private_key.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives (e.g., importing a key or generating with specific curves). No comparison with siblings like _import_private_key or _get_key_info is provided.

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

_get_key_infoD

Get information about a key

ParametersJSON Schema

Name	Required	Default
`private_key`	No
`public_key`	No
`curve`	No	NIST256p
`hashfunc`	No	sha256

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.8/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It fails to explain what happens with multiple or no keys, the role of curve and hashfunc parameters, or any error conditions. The output schema is present but its contents are not described.

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 is overly terse, sacrificing clarity for brevity. While concise, it lacks essential detail that would make it useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, all optional with defaults, an existing output schema, and many siblings, the description is severely incomplete. It does not explain return values, relationships between parameters, or typical usage scenarios.

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

Parameters1/5

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

With 0% schema description coverage, the description must explain parameters but does not. The purpose of private_key, public_key, curve, and hashfunc is entirely unclear from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get information about a key' is a tautology, restating the tool name without specifying what information is provided or how it differs from sibling tools like _export_private_key or _export_public_key.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when-not-to-use, or how it relates to sibling tools.

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

_import_private_keyC

Import a private key from various formats

ParametersJSON Schema

Name	Required	Default
`key_data`	Yes
`format`	Yes
`curve`	No	NIST256p
`hashfunc`	No	sha256

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.3/5.0

Behavior1/5

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

No annotations exist and the description fails to disclose any behavioral traits like side effects, permissions, or error conditions.

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?

While short, the single sentence is under-specified and does not earn its place by providing necessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given four parameters and an output schema, the description is completely inadequate, lacking information on return values, conflict behavior, and valid input formats.

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

Parameters1/5

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

With 0% schema description coverage, the description does not explain any of the four parameters (e.g., key_data format, allowed format values, curve/hashfunc options).

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 clearly states the tool imports a private key, and the resource and action are distinct from sibling tools like export, generate, and import public key.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as generate_key or recover_public_key.

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

_import_public_keyC

Import a public key from various formats

ParametersJSON Schema

Name	Required	Default
`key_data`	Yes
`format`	Yes
`curve`	No	NIST256p
`hashfunc`	No	sha256

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, and description lacks behavioral details: impact on existing keys, validation, error conditions. For a mutating operation, this is insufficient.

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

Conciseness3/5

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

The description is short but not informative; it earns its place but fails to add value beyond the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters, no annotations, and an output schema not explained, the description is inadequate. It does not cover return value, format validation, or typical usage.

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

Parameters1/5

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

0% schema description coverage and no parameter explanations in description. key_data, format, curve, hashfunc are undefined, leaving the agent guessing.

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 clearly states the action (import) and resource (public key) from various formats. It distinguishes from sibling tools like _import_private_key and _export_public_key.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like _import_private_key or _recover_public_key. No mention of supported formats or prerequisites.

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

_recover_public_keyC

Recover public keys from a signature and signed data

ParametersJSON Schema

Name	Required	Default
`signature`	Yes
`data`	Yes
`curve`	No	NIST256p
`hashfunc`	No	sha256

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior, but it only says 'recover public keys' without mentioning algorithm support, error conditions, or return format. This is insufficient for an AI agent.

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

Conciseness3/5

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

The description is a single sentence, which is concise but overly minimal. It could include more information without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no annotations, and an output schema not referenced, the description lacks completeness. It does not explain how or when to use the optional parameters or what the output contains.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention any parameter. It adds no meaning beyond the schema's bare types and names, leaving agents without usage hints for 'curve' and 'hashfunc'.

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 clearly states the tool recovers public keys from a signature and signed data, using a specific verb and resource. It distinguishes from siblings like _export_public_key and _verify_signature.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Agents receive no context for selection.

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

_sign_dataC

Sign data using ECDSA

ParametersJSON Schema

Name	Required	Default
`private_key`	Yes
`data`	Yes
`curve`	No	NIST256p
`hashfunc`	No	sha256
`sigencode`	No	string
`deterministic`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral disclosure burden. It only says 'Sign data using ECDSA' and does not explain effects like whether data should be raw or hashed, error handling, or the role of parameters like 'deterministic' and 'sigencode'. This is insufficient for safe invocation.

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

Conciseness3/5

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

The description is extremely concise (one sentence), but it lacks structure such as parameter highlights or usage notes. While brevity is good, it sacrifices informativeness. A well-structured short description could include key details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity (6 parameters, output schema) and lack of annotations, the description is severely incomplete. It does not explain input/output formats, required parameter details, or error behavior. This leaves the agent underinformed for correct invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no parameter explanations. It does not elaborate on private_key format, data format, curve options, hash function, signature encoding, or determinism. The description fails to compensate for the missing schema descriptions.

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 states it signs data using ECDSA, which is a specific verb+resource (sign + data) and mentions the algorithm (ECDSA), distinguishing it from non-signing siblings. However, it does not clarify the difference from _sign_digest or specify input/output formats, so it is not maximally clear.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like _sign_digest or _verify_signature. The description does not mention prerequisites, context, or exclusion cases, leaving the agent without decision support.

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

_sign_digestC

Sign a digest directly using ECDSA (no hashing)

ParametersJSON Schema

Name	Required	Default
`private_key`	Yes
`digest`	Yes
`curve`	No	NIST256p
`sigencode`	No	string
`deterministic`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

The description discloses that the tool signs a pre-hashed digest without additional hashing, which is a key behavioral trait. However, with no annotations provided, it fails to explain other important aspects such as error handling, output format, or security implications.

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 a single concise sentence, which is efficient for a straightforward operation. However, it lacks any structural elements like bullet points or sections, and could benefit from additional information without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of five parameters with zero schema documentation, no annotations, and an output schema that likely describes return values, the description does not sufficiently compensate. It omits crucial context for correct invocation, such as parameter formats or usage constraints.

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 description coverage is 0%, and the description does not elaborate on any of the five parameters (private_key, digest, curve, sigencode, deterministic). Users are left to guess formats or valid values, reducing the tool's usability.

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 states the verb 'Sign' and the resource 'digest', and specifies the method 'using ECDSA (no hashing)', which distinguishes it from related tools like _sign_data that likely perform hashing. However, it does not explicitly contrast with siblings.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like _sign_data or _verify_digest_signature. There is no mention of prerequisites, input format requirements, or when not to use it.

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

_verify_digest_signatureC

Verify a signature over a digest

ParametersJSON Schema

Name	Required	Default
`public_key`	Yes
`signature`	Yes
`digest`	Yes
`curve`	No	NIST256p
`sigdecode`	No	string

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are provided, and the description fails to disclose any behavioral traits such as return values, error conditions, or side effects. The description is purely restating the tool's name.

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 is extremely short but at the cost of essential information. It is not appropriately front-loaded with key details; it is merely a phrase.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and schema descriptions, the description is severely inadequate. An output schema exists but its content is not utilized to compensate. The tool's behavior and parameter usage remain largely unspecified.

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

Parameters1/5

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

With 0% schema coverage, the description adds no information about the five parameters. The agent receives no guidance on parameter roles, formats, or the meaning of curve and sigdecode defaults.

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 specifies the verb 'Verify' and the resource 'signature over a digest', clearly indicating the operation. It distinguishes from sibling tools like _sign_digest by focusing on verification, but does not explicitly differentiate from _verify_signature.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives such as _verify_signature or _sign_digest. The agent is left to infer from the name and context.

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

_verify_signatureC

Verify an ECDSA signature

ParametersJSON Schema

Name	Required	Default
`public_key`	Yes
`signature`	Yes
`data`	Yes
`curve`	No	NIST256p
`hashfunc`	No	sha256
`sigdecode`	No	string

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations provided, the description must bear the full burden of disclosing behavior. It only states the action (verify) but does not mention return values (e.g., boolean), error handling, side effects (none), or required input formats. The presence of an output schema implies structured output, but the description omits any details.

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 is extremely short (one sentence) but under-specified. True conciseness would convey all critical information in minimal words; this only gives the purpose, omitting essential details about behavior and parameters, making it insufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters, 0% schema coverage, an output schema, and no annotations, the description is wholly inadequate. It provides no context about verification process, encoding, curve types, hash functions, or expected output, leaving the agent with little to no guidance.

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

Parameters1/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 compensate. It fails to add any meaning to the 6 parameters, not explaining what public_key, signature, data, curve, hashfunc, or sigdecode represent. The agent gets no help understanding required formats or the role of optional parameters beyond their names.

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 states it verifies an ECDSA signature, specifying the verb 'verify' and the resource 'ECDSA signature'. However, it does not distinguish from the sibling tool _verify_digest_signature, which likely verifies a pre-hashed digest instead of raw data.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of when to choose this over _verify_digest_signature or other sibling tools, leaving the agent to infer from the name alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv0.1.1May 29, 2026
- First observed_export_private_key
- First observed_export_public_key
- First observed_generate_key
- First observed_get_key_info
- First observed_import_private_key
- First observed_import_public_key
- First observed_recover_public_key
- First observed_sign_data
- First observed_sign_digest
- First observed_verify_digest_signature
- First observed_verify_signature

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation5/5

Each tool has a distinct purpose: key generation, import/export, signing, verification, and recovery. Even though signing and verification have two variants each (data vs digest), they are clearly differentiated by whether hashing is performed.

Naming Consistency5/5

All tool names follow the snake_case pattern with a verb_noun structure (e.g., _export_private_key, _sign_data). The underscore prefix is consistent across all tools, making the naming predictable.

Tool Count5/5

With 11 tools covering key lifecycle (generate, import/export, info) and signing/verification operations, the count is well-scoped for an ECDSA server. It provides necessary functionality without redundancy.

Completeness4/5

The set covers core ECDSA operations: key management, signing, verification, and public key recovery. A minor gap is the lack of a key deletion tool, but this does not hinder typical signing workflows.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

CipherHUB Cryptography Toolkit A
io.github.bowenerchen
Production-grade cryptography toolkit with 31 MCP tools for classical, PQC, and KMS workflows.
Security Developer Tools
422
MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
111
James's MCP Server A
io.github.JGPAS
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
21
mcp-klever-vm A
io.github.klever-io
MCP server for Klever blockchain smart contract development.
Blockchain Developer Tools Code Execution
16331

Related MCP Servers

local-kms-mcp-server
Security Autonomous Agents
Diegoescalonaro
A
license
A
quality
B
maintenance
Local-first MCP server for per-agent key management, generating and using signing keys without external KMS.
Updated 15 days ago (2026-08-22 16:37 UTC)
8
72
1
MIT
dpay-mcp
Blockchain Cryptocurrency Web3 & Decentralized Tech
programmaman
A
license
A
quality
B
maintenance
An MCP server for creating, settling, disputing, and refunding escrows on EVM chains.
Updated 2 months ago (2026-07-11 22:07 UTC)
8
14
Apache 2.0
Trust OS MCP Serverofficial
Security Finance
trustos-trustfolio
A
license
A
quality
B
maintenance
MCP server for verifying high-impact decisions with Trust OS.
Updated a month ago (2026-08-05 03:42 UTC)
2
MIT
fallvault-mcp
Security
sjgant80-hub
A
license
Not graded
quality
C
maintenance
MCP server for sovereign AES-256-GCM backup encryption and decryption. Enables encrypting, decrypting, verifying, and scoring passphrases with zero network calls.
Updated 2 months ago (2026-07-09 15:41 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/daedalus/mcp-ecdsa'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-ecdsa

Install

Usage

As MCP Server

Python API

Tools

Supported Curves

Supported Hash Functions

Development

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Trust OS MCP Serverofficial

Latest Blog Posts

MCP directory API