SSIG MCP

by mrq1911

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct role: three chain-specific request tools, one status getter, one list, and one cancel. No two tools overlap in function; even the three request tools are clearly differentiated by chain.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., request_evm_transaction, get_transaction_request, list_transaction_requests). The pattern is uniform and predictable.
Tool Count5/5
Six tools is well-scoped for a transaction request manager: three chain-specific creation methods plus three lifecycle operations. Each tool earns its place without unnecessary duplication.
Completeness5/5
The tool surface covers the full lifecycle of transaction requests: create (for each supported chain), read (single and list), and cancel. No obvious gaps for the stated purpose.
Average 4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent safety. The description adds a valuable behavioral note that serialized transaction payloads are omitted, which sets expectations about the response and hints that get_transaction_request should be used for payloads.
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?
One sentence with the core purpose and a critical omission note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no mention of the statuses filter, the description leaves gaps. It tells what is omitted but not what is included, and doesn't explain filtering behavior.
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?
The single parameter 'statuses' is entirely undocumented in the description, and schema coverage is 0%. The enum values are self-explanatory, but the description adds no meaning about how filtering works or what the parameter does.
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 lists recent approval requests, using a specific verb and resource. It distinguishes from siblings like get_transaction_request (single fetch) and request_* (creation) by its list nature.
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 does not explicitly state when to use this tool versus alternatives. It implies a browsing use case with 'recent' but offers no guidance on filtering by status or when to prefer get_transaction_request for specific details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses that transactions are simulated and queued pending explicit user approval, and that asciiExplanation must be a plain-ASCII risk explanation. This adds behavioral context beyond readOnlyHint/idempotentHint flags, though it does not clarify post-approval submission behavior.
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?
Two sentences, front-loaded with action, no filler. The second sentence adds a critical constraint without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, 2 enums, no output schema), the description covers core function and the critical parameter but omits expected return values or behavior after approval (e.g., sign vs sign-and-submit).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 29%, the description compensates by emphasizing asciiExplanation requirements (ASCII-only, content requirements). However, other parameters like mode, network, and expectedSigner are left to schema enums, limiting added semantics.
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 specific verbs 'simulate and queue' and identifies the resource as a serialized Solana transaction for explicit approval via Wallet Standard. It clearly differentiates from sibling tools by network (Solana) and action (request approval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Solana transaction approvals but does not explicitly contrast with sibling alternatives like request_evm_transaction or get_transaction_request. There is no when-not-to-use guidance, only the implied network-specific context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive/non-read-only behavior, so the bar is lower. The description adds valuable context by specifying exactly what is affected (the pending browser approval request) and adding the 'still-pending' state requirement, which goes beyond the basic destructiveHint. This enriches the agent's understanding of the tool's effect.
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, seven-word sentence that is front-loaded with the verb and object. It contains no filler words or redundant information. Every word contributes meaning, making it exemplary in conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with annotations, the description covers the core action and state condition. However, it does not explain what happens when the request is not pending, nor does it clarify how to obtain the requestId. Given the absence of an output schema and the tool's simplicity, the description is adequate but has clear gaps in error handling and parameter linkage.
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?
The schema has zero description coverage for the only parameter, requestId, and the tool description does not mention it at all. The description fails to compensate for the low schema coverage, leaving the agent to infer that requestId is the identifier of the request to cancel from the tool name. This is a minimal, but not absent, semantic connection.
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 the specific verb 'Cancel' and identifies the resource as 'a still-pending browser approval request,' which clearly distinguishes it from sibling tools like request/review or list transactions. The qualifier 'still-pending' adds precision about the target state. This is a clear, specific purpose statement.
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?
The description implies when to use the tool: for cancelling a request that is still pending approval. It also implicitly excludes non-pending requests, serving as a usage condition. However, it does not explicitly reference alternatives or explain when not to use it beyond the pending-state constraint, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by noting the tool simulates and queues transactions rather than immediately submitting them. The mandatory asciiExplanation requirement is also disclosed, which is a non-obvious behavioral constraint.
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 two sentences long, immediately stating the purpose and then highlighting the most critical input constraint. No wasted words, with essential information front-loaded.
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?
The description omits important context about the transaction approval lifecycle, such as how a queued request is later retrieved or canceled, and does not explain the difference between 'sign' and 'sign-and-submit' modes. Given the presence of sibling tools for these operations, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 29%, but the description adds meaning to key parameters: transactionBase64 is described as serialized Sui TransactionData, and asciiExplanation is described as ASCII-only and required. Other parameters (mode, network, expectedSigner, expiresInMinutes) rely on schema enums and are left unexplained.
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 simulates and queues serialized Sui TransactionData for explicit approval, specifying the exact resource (Sui) and action (simulate/queue). This distinguishes it from sibling tools for EVM and Solana transactions.
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?
The description implies this is the tool for Sui transactions via the explicit 'Sui Wallet Standard extension' and 'serialized Sui TransactionData'. However, it does not explicitly mention when to prefer this over the EVM/Solana request tools or cancellation/retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds the useful context that it returns the latest status and wallet result, which is beyond what annotations convey. No contradictions.
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?
A single, concise sentence that front-loads the verb and resource. Every word adds value with no redundancy or filler.
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 simple read-only tool with one parameter and strong annotations, the description is sufficient. It specifies what is read and the key output (status and wallet result), and the ownership of the output is clear. No output schema exists, but the description covers the essential return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 only implicitly indicates that requestId refers to the transaction request being read ('for one transaction request'), but does not elaborate on format or meaning beyond the schema, which already specifies uuid format. The single parameter is self-explanatory, but little added value.
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 a specific verb ('Read') and resource ('one transaction request'), and specifies what is returned ('latest status and wallet result'). It distinguishes from sibling tools like list_transaction_requests (plural) and cancel_transaction_request (write operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a single transaction request's status is needed, but does not explicitly mention when not to use it or name alternatives. It lacks guidance like 'use list_transaction_requests for multiple requests' or 'use cancel_transaction_request to modify a request'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it states the tool simulates before queueing, never claims signature before approval, and enforces asciiExplanation constraints. This complements the annotations (readOnlyHint=false, openWorldHint=true) 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences, front-loads the core function, and adds a critical safety caveat and a mandatory parameter rule without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary action and key safety detail, but doesn't explain the sign vs sign-and-submit modes, return values, or lifecycle of the queued request. Given the absence of an output schema and presence of a nested transaction object, additional context would help the agent use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only asciiExplanation receives enhanced semantic guidance in the description, restating and expanding on the schema's requirement. The many other parameters (mode, chainId, transaction fields) are left to the schema, which is sparse given only 13% schema description coverage; the description could have compensated more.
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 opens with 'Simulate and queue an EVM transaction for explicit browser-wallet approval,' which clearly identifies the action (simulate/queue) and resource (EVM transaction) and distinguishes it from sibling tools like request_solana_transaction or list_transaction_requests. The additional caveat about not claiming signature reinforces the tool's role.
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?
The description implies the tool should be used when an EVM transaction needs user approval, and the name/description differentiate it from Solana/Sui variants. However, it does not explicitly state when to use this over the get/list/cancel transaction request tools, nor does it describe prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ssig-mcp MCP server](https://glama.ai/mcp/servers/mrq1911/ssig-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mrq1911/ssig-mcp)

Score Badge

Copy to your README.md:

[![ssig-mcp MCP server](https://glama.ai/mcp/servers/mrq1911/ssig-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mrq1911/ssig-mcp)

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/mrq1911/ssig-mcp'

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