Stampchain MCP Server

Official

by stampchain-io

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different resources (stamps, collections, tokens, market data), but there is some overlap between get_market_data and get_stamp_market_data which could cause confusion. The descriptions clarify that one is general and one is stamp-specific, but the naming similarity might lead to misselection.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with clear prefixes like get_, search_, and analyze_. All use snake_case consistently, making the set predictable and easy to understand at a glance.
Tool Count5/5
With 13 tools, the count is well-scoped for a server focused on Bitcoin stamps, collections, tokens, and market data. Each tool appears to serve a specific function without redundancy, fitting the domain's complexity appropriately.
Completeness4/5
The tool set covers key operations like retrieval (get_), search, and analysis for stamps, collections, and tokens, with market data features included. Minor gaps might exist, such as no explicit update or delete tools, but these may not be needed for the domain's read-heavy nature, and agents can likely work around this.
Average 2.9/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions analysis activities (parsing, resolution, detection), it doesn't describe what the tool actually returns, whether it's computationally intensive, if there are rate limits, or what 'security analysis' and 'performance analysis' entail. For a complex 6-parameter tool with no output schema, this leaves significant behavioral gaps.
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, efficient sentence that packs substantial information about the tool's scope. It front-loads the core purpose and lists key analysis components. While dense, every element serves a purpose in conveying what the tool does. No wasted words or redundant 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?
For a complex analysis tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what format the analysis results take, what 'recursive stamp' means in this context, or how the different analysis components (security, performance) relate to each other. The agent would struggle to understand what to expect from using this tool.
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 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. It mentions 'dependency resolution' which relates to 'include_dependencies' and 'max_depth', but doesn't provide additional context about how these parameters interact or affect the analysis.
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 tool analyzes code structure and dependencies of a recursive stamp, specifying JavaScript parsing, dependency resolution, and pattern detection. It distinguishes itself from simpler sibling tools like 'get_stamp' or 'get_stamp_dependencies' by offering comprehensive analysis. However, it doesn't explicitly differentiate from 'analyze_stamp_patterns' which might overlap in pattern detection functionality.
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. With sibling tools like 'get_stamp_dependencies' and 'analyze_stamp_patterns' available, there's no indication of when this comprehensive analysis tool is preferable over more focused tools. No prerequisites, exclusions, or comparative context is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing patterns and identifying common elements, but doesn't cover critical aspects like whether this is a read-only or mutating operation, performance characteristics (e.g., computational cost, rate limits), authentication needs, or what the output format looks like (since there's no output schema). This is a significant gap for a tool with 6 parameters and no annotation coverage.
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, efficient sentence that front-loads the core purpose without unnecessary details. It's appropriately sized for the tool's complexity, with zero waste or redundancy. However, it could be slightly improved by structuring it to hint at key parameters or outcomes, but it's already very concise.
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 tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It adequately states the purpose but fails to provide behavioral context, usage guidelines, or output expectations. Without annotations or an output schema, the description should do more to explain what the tool returns or how it behaves, making it insufficient for effective agent use.
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?
The input schema has 100% description coverage, with each parameter well-documented (e.g., 'sample_size' as 'Number of stamps to analyze for patterns'). The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters or usage nuances. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 tool's purpose: 'Analyze patterns across multiple recursive stamps to identify common libraries, frameworks, and coding techniques used in the ecosystem.' It specifies the verb ('analyze'), resource ('recursive stamps'), and outcome ('identify common libraries, frameworks, and coding techniques'). However, it doesn't explicitly differentiate from siblings like 'analyze_stamp_code' or 'search_stamps', which might have overlapping functionality, so it falls short of a perfect score.
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. With siblings like 'analyze_stamp_code', 'search_stamps', and 'get_stamp_dependencies', there's no indication of context, prerequisites, or exclusions. It lacks explicit when/when-not instructions or named alternatives, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'trading activity indicators' but doesn't explain what these are, how data is retrieved (e.g., real-time vs. cached), rate limits, authentication needs, or error handling. For a data retrieval tool with no annotation coverage, this is insufficient to inform the agent about operational behavior.
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, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by separating version info or adding brief context. Overall, it's appropriately sized for its content.
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 complexity of a market data tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on return values (e.g., data format, included fields), behavioral traits (e.g., pagination behavior, data freshness), and differentiation from siblings. This leaves significant gaps for the agent to understand the tool's full context.
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?
The input schema has 100% description coverage, providing clear details for all 7 parameters (e.g., filters, pagination). The description adds no additional parameter semantics beyond implying 'trading activity indicators' might relate to the 'activity_level' enum. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
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 tool's purpose: 'Retrieve market data for stamps with trading activity indicators'. It specifies the resource (market data for stamps) and includes a version reference (v2.3 feature). However, it doesn't explicitly differentiate from sibling tools like 'get_stamp_market_data' or 'get_recent_sales', which reduces clarity about when to choose this specific tool.
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. With multiple sibling tools related to stamps and market data (e.g., get_stamp_market_data, get_recent_sales, search_stamps), there is no indication of context, prerequisites, or comparisons. This leaves the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication requirements, or what happens when parameters are omitted. The mention of 'enhanced transaction details' hints at richer output but doesn't specify format or limitations.
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, efficient sentence that front-loads the core purpose. However, it could be more structured by explicitly mentioning key parameters like date range filtering, which is implied but not stated.
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?
For a tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or how parameters interact (e.g., combining stamp_id with dayRange). The mention of 'v2.3 feature' is useful but doesn't compensate for missing behavioral context.
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 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond implying 'enhanced transaction details' relates to the 'fullDetails' parameter, but doesn't explain what 'enhanced' means or provide additional context about parameter interactions.
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 'retrieve' and resource 'recent stamp sales', specifying it provides 'enhanced transaction details' as a v2.3 feature. It distinguishes from siblings like 'get_recent_stamps' by focusing on sales rather than stamps themselves, though it doesn't explicitly mention this distinction.
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 like 'get_market_data' or 'get_recent_stamps'. It mentions 'enhanced transaction details' as a feature but doesn't explain when this is preferable over simpler queries or other sales-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't cover key traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the return format looks like (e.g., list of stamps with details). This is inadequate for a tool with no annotation support.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'Bitcoin stamps' are, what data is returned (e.g., fields like ID, timestamp, content), or behavioral aspects like pagination or errors. For a tool with no structured support, this leaves significant gaps for an agent.
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?
The input schema has 100% description coverage, fully documenting the 'limit' parameter with details on type, range, and default. The description adds no additional parameter semantics beyond implying 'recent' ordering, which is already suggested by the tool name. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'Retrieve' and resource 'most recently created Bitcoin stamps', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_recent_sales' or 'search_stamps', which might also retrieve recent stamps with different filters or scopes.
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 such as 'get_stamp' for specific stamps or 'search_stamps' for filtered searches. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves detailed information but doesn't disclose behavioral traits such as error handling (e.g., what happens with invalid IDs), rate limits, authentication needs, or response format. This leaves significant gaps for an agent to understand how to invoke it safely.
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, efficient sentence that front-loads the core purpose ('retrieve detailed information') and specifies the key constraint ('by its ID'). There is zero waste, and every word earns its place, making it highly concise and well-structured.
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 tool has no annotations, no output schema, and involves retrieving data (which could include complex details like ownership or metadata), the description is incomplete. It doesn't cover what 'detailed information' entails, potential errors, or response structure, leaving the agent with insufficient context for reliable use.
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 100%, so the schema fully documents both parameters ('stamp_id' and 'include_base64'). The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain what 'detailed information' includes or how base64 data is structured). Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('retrieve') and resource ('detailed information about a specific Bitcoin stamp'), making the purpose evident. It distinguishes from siblings like 'get_recent_stamps' or 'search_stamps' by specifying retrieval of a single stamp by ID. However, it doesn't explicitly contrast with all siblings (e.g., 'get_token_info' might overlap in some contexts).
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 like 'search_stamps' or 'get_token_info'. It mentions retrieving by ID but doesn't clarify prerequisites (e.g., needing a valid stamp ID) or exclusions (e.g., not for batch retrieval). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves data (implying read-only) but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what 'detailed market data' includes (e.g., pricing, trends, availability). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic purpose.
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, efficient sentence that states the core purpose and includes a version note. It's appropriately sized for a simple tool, with no wasted words. However, the version note 'v2.3 feature' could be considered slightly extraneous if not critical for usage, but it doesn't significantly detract from conciseness.
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 no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what 'detailed market data' returns, potential errors, or usage constraints. For a tool with siblings offering similar data, more context is needed to understand its role and output. The version note adds some context but doesn't compensate for missing behavioral and output details.
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?
The description adds no parameter semantics beyond what the schema provides. The input schema has 100% description coverage, with the single parameter 'stamp_id' documented as 'The ID of the stamp to get market data for'. The description doesn't elaborate on ID format, examples, or constraints. With high schema coverage, the baseline is 3, as the schema does the heavy lifting.
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 ('retrieve') and resource ('detailed market data for a specific stamp'), making the purpose understandable. It distinguishes from siblings like 'get_market_data' (likely general) and 'get_stamp' (likely basic info) by specifying 'detailed market data' and 'specific stamp', though it doesn't explicitly contrast them. The version note 'v2.3 feature' adds context but doesn't affect core purpose clarity.
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. With siblings like 'get_market_data' (possibly broader market data), 'get_stamp' (likely general stamp info), and 'get_recent_sales' (possibly sales-focused data), there's no indication of when this specific tool is appropriate. The version note implies it's for newer features but doesn't help choose between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't disclose any behavioral traits like rate limits, authentication needs, error handling, or what 'detailed information' includes beyond the parameters. This leaves significant gaps for an agent to understand how to interact with it effectively.
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, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool, making it easy for an agent to parse quickly.
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 complexity of retrieving token information with optional parameters (include_holders, include_transfers) and no output schema, the description is incomplete. It doesn't explain what 'detailed information' entails, how the optional parameters affect the output, or any response format, leaving the agent with insufficient context for proper usage.
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 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying the ticker symbol is the primary identifier, which is covered in the schema. This meets the baseline score of 3 when the schema does the heavy lifting.
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 ('retrieve') and resource ('detailed information about a specific SRC-20 token'), specifying it's by ticker symbol. However, it doesn't explicitly differentiate from sibling tools like 'search_tokens' or 'get_collection', which might retrieve token information differently.
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 like 'search_tokens' or 'get_collection'. It lacks context about prerequisites, such as needing a valid ticker symbol, and doesn't mention any exclusions or specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'various filtering criteria' but doesn't explain what happens when no filters are applied, whether results are paginated (implied by schema but not stated), what the response format looks like, or any rate limits/authentication requirements. For a search tool with 6 parameters, this leaves significant behavioral questions unanswered.
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, efficient sentence that gets straight to the point. Every word contributes to understanding the tool's purpose without any fluff or redundancy. It's appropriately sized for a search tool and front-loads the essential 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?
For a search tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what constitutes a 'stamp collection' versus individual stamps, what fields are searchable beyond name/description, what the response contains, or how results are structured. The agent would need to guess about important behavioral aspects despite having a complete parameter schema.
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?
The schema description coverage is 100%, so all parameters are well-documented in the schema itself. The description adds minimal value beyond stating 'various filtering criteria' - it doesn't explain how parameters interact, what 'creator address' means in context, or provide examples of effective queries. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('search') and resource ('stamp collections'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'search_stamps' or 'search_tokens' - both are search tools for different resources. The description could be more specific about what makes stamp collections unique versus other searchable entities.
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. With multiple search tools available (search_stamps, search_tokens), the agent has no indication whether this is for collections of stamps versus individual stamps versus tokens. There's no mention of prerequisites, typical use cases, or relationships to other tools like 'get_collection'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but doesn't describe important behavioral aspects: whether this is a read-only operation, what the response format looks like (e.g., list of stamps with metadata), pagination behavior (implied by page/page_size parameters but not explained), rate limits, authentication requirements, or error conditions. For a search tool with 9 parameters, this leaves significant gaps in understanding how the tool behaves.
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, well-structured sentence that efficiently communicates the core functionality. It's appropriately sized for a search tool and front-loads the main purpose. There's no unnecessary repetition or verbose explanations, though it could potentially benefit from a brief second sentence about typical use cases or limitations.
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 tool's complexity (9 parameters, search functionality) and lack of both annotations and output schema, the description is insufficiently complete. It doesn't explain what constitutes a 'Bitcoin stamp' in this context, what data is returned, how results are structured, or any limitations on search scope. For a tool that likely returns complex data structures, the description should provide more context about the expected output and behavioral characteristics.
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 100%, meaning all parameters are documented in the schema itself. The description adds minimal value beyond the schema by mentioning 'creator, collection, and stamp type' as examples of filtering criteria, but doesn't provide additional context about parameter relationships, typical values, or usage patterns. The baseline score of 3 reflects adequate but not enhanced parameter documentation given the comprehensive schema coverage.
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 ('Search for Bitcoin stamps') and resource ('Bitcoin stamps'), making the purpose immediately understandable. It specifies the filtering capabilities ('with various filtering criteria including creator, collection, and stamp type'), which helps distinguish it from simple retrieval tools. However, it doesn't explicitly differentiate from sibling tools like 'search_collections' or 'search_tokens' beyond mentioning 'Bitcoin stamps'.
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. It doesn't mention sibling tools like 'get_recent_stamps' (for recent items without filtering), 'search_collections' (for collections rather than stamps), or 'get_stamp' (for retrieving a specific stamp by ID). There's no indication of prerequisites, limitations, or typical use cases beyond the basic search functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't mention whether this is a read-only operation, potential rate limits, authentication needs, or what the response format looks like (e.g., paginated results). The phrase 'Search for' implies a query operation, but lacks details on performance, errors, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Search for SRC-20 tokens with various filtering criteria') contributes directly to understanding the tool's function, making it appropriately sized and well-structured.
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 tool's complexity (8 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what constitutes an SRC-20 token, typical search scenarios, or the structure of returned results. For a search tool with multiple filtering options and pagination, more context about expected outputs and behavioral constraints is needed for effective agent use.
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 100%, providing detailed documentation for all 8 parameters. The description adds no additional parameter semantics beyond mentioning 'various filtering criteria', which is already covered by the schema. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance understanding of parameter interactions or typical usage patterns.
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 ('Search for') and resource ('SRC-20 tokens'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'search_collections' or 'search_stamps' beyond specifying the resource type, missing an opportunity for explicit differentiation.
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 like 'search_collections', 'search_stamps', or 'get_token_info'. It mentions 'various filtering criteria' but doesn't specify typical use cases, prerequisites, or exclusions, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't mention potential side effects, authentication needs, rate limits, or response format. For a tool with 4 parameters and no annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that front-loads the core purpose ('retrieve detailed information about a specific stamp collection by its ID') with zero wasted words. Every part of the sentence contributes directly to understanding the tool's function.
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 no annotations and no output schema, the description adequately covers the basic purpose but lacks details on behavioral traits, response format, and usage context. For a retrieval tool with 4 parameters, it provides a minimal viable foundation but doesn't fully compensate for the missing structured data, leaving room for improvement in completeness.
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 100%, so the schema fully documents all 4 parameters (collection_id, include_stamps, stamps_page, stamps_limit). The description adds no parameter-specific information beyond implying the collection_id is required, which is already clear from the schema. This meets the baseline for high schema coverage.
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 'retrieve' and the resource 'detailed information about a specific stamp collection by its ID', making the purpose unambiguous. It distinguishes from siblings like 'search_collections' by focusing on a single collection rather than searching multiple. However, it doesn't explicitly contrast with 'get_stamp' or other get_* tools, preventing a perfect score.
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 like 'search_collections' for finding collections or 'get_stamp' for individual stamps. It mentions retrieving by ID but doesn't specify prerequisites (e.g., needing the ID first) or exclusions, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions creating a graph but lacks details on performance implications (e.g., speed for deep graphs), error handling, or output specifics, leaving gaps in understanding how the tool behaves.
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, efficient sentence that front-loads the core purpose without unnecessary words, making it easy to grasp quickly and earning its place.
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 tool's complexity (dependency mapping with 5 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain return values, error cases, or behavioral nuances, leaving critical gaps for effective use.
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 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond implying dependency traversal, which aligns with the schema but doesn't enhance parameter understanding beyond what's already provided.
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 specific action ('create a hierarchical dependency graph') and resource ('recursive stamp'), distinguishing it from siblings like 'get_stamp' or 'analyze_stamp_code' by focusing on dependency mapping rather than retrieval or analysis.
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. It does not mention prerequisites, exclusions, or compare with sibling tools like 'get_stamp' or 'analyze_stamp_patterns', leaving usage context unclear.
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:

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

Score Badge

Copy to your README.md:

[![stampchain-mcp MCP server](https://glama.ai/mcp/servers/stampchain-io/stampchain-mcp/badges/score.svg)](https://glama.ai/mcp/servers/stampchain-io/stampchain-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/stampchain-io/stampchain-mcp'

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