Lightyear CryptoPunks
Server Details
Browse traits, filter 10K punks, listings, bids, Merkle roots, and bid pricing for CryptoPunks.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 11 of 11 tools scored. Lowest: 3.7/5.
Every tool has a clearly distinct purpose, from browsing traits and types to computing Merkle roots and fetching bids. There is no overlap or ambiguity between tool functions.
All tool names follow a consistent verb_noun pattern with underscores (e.g., browse_traits, get_listings, compute_merkle_root), making the API predictable and easy to navigate.
With 11 tools, the server covers the core domain of CryptoPunks market data without being bloated or too sparse. Each tool serves a clear purpose in the workflow.
The tool surface covers browsing, filtering, Merkle root operations, bid queries, floor price, listings, and recommendations. No obvious gaps for a read-only market data server focused on CryptoPunks.
Available Tools
11 toolsbrowse_traitsARead-onlyInspect
List all CryptoPunk traits with their counts. Optionally filter by type to see how many punks of that type have each trait. Rate limit: 10 per 10 min (read bucket — shared with browse_types, get_punk_details, get_listings, get_floor_price, get_bids_for_punk, get_bids_for_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter counts to a specific type (e.g. 'Male', 'Zombie') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying rate limits (10 per 10 min) and shared bucket. No contradiction. However, it does not detail return format or pagination, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main purpose, no waste. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema), the description covers purpose, optional filter, and rate limit. Missing return format details but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'type' parameter. The description adds meaning by explaining how the filter affects output (counts per trait for that type).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all CryptoPunk traits with counts and optionally filters by type. It distinguishes itself from sibling tools like browse_types and filter_punks by focusing on trait enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by type and provides rate limit details, including shared bucket with sibling tools. While it does not explicitly state when to use this tool versus alternatives, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browse_typesARead-onlyInspect
List all CryptoPunk type categories with their counts. Rate limit: 10 per 10 min (read bucket — shared with browse_traits, get_punk_details, get_listings, get_floor_price, get_bids_for_punk, get_bids_for_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds rate limit details and mentions shared bucket with sibling tools, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: one for purpose, one for rate limit. No fluff, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description could hint at return structure, but the simple nature (list of types with counts) makes the description adequate. Rate limit context enhances completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds no parameter info, which is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'CryptoPunk type categories with their counts'. It is specific and distinguishes from sibling tools like browse_traits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 browse_traits. The rate limit information is provided but lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_merkle_rootARead-onlyInspect
Compute the Merkle root for a set of CryptoPunk IDs. The root matches the on-chain Solady MerkleProofLib encoding used by the Stash contract. Rate limit: 5 per 10 min (compute bucket — shared with filter_punks, resolve_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
| punkIds | Yes | Punk IDs to include in the Merkle tree (1-10000) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which is consistent with 'compute'. The description adds rate limit context, but does not detail behavior for invalid inputs or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second adds encoding and rate limit. No fluff, efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description does not mention return value (e.g., the root). Rate limit info is good, but missing output details makes it incomplete for a compute tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the 'punkIds' parameter. The description adds no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes a Merkle root for CryptoPunk IDs, specifying the encoding and contract. However, it does not explicitly differentiate from the sibling tool 'resolve_merkle_root', which might have a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides rate limit info and shared bucket with siblings, which is helpful. But lacks explicit guidance on when to use this tool versus alternatives, such as 'resolve_merkle_root'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
filter_punksARead-onlyInspect
Filter CryptoPunks by type and traits. Returns matching punk IDs and their Merkle root. Rate limit: 5 per 10 min (compute bucket — shared with compute_merkle_root, resolve_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Type names to include (e.g. ['Male', 'Zombie']). Empty = all types. | |
| matchMode | No | 'all' = punk must have every included trait, 'any' = at least one | all |
| excludedTraits | No | Traits to exclude | |
| includedTraits | No | Traits to include |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds the rate limit and shared compute bucket, which is valuable behavioral context beyond annotations. No contradictions exist. It does not detail side effects (none expected for read-only), but the added constraints are helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences: one for purpose, one for return value, one for rate limit. Every sentence carries unique information, no redundancy, and it is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters and no output schema, the description covers return value and rate limit constraints. For a read-only filter, it is mostly complete. However, it could improve by briefly noting how types and traits interact (e.g., whether types filter independently or overlap).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the base is 3. The description mentions filtering by 'type and traits' but does not elaborate on parameter specifics; the schema already provides clear descriptions for types, matchMode, excludedTraits, and includedTraits. The description adds no new semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Filter CryptoPunks by type and traits' with a precise verb and resource. It specifies the return value (matching punk IDs and Merkle root), making the tool's purpose unambiguous. Among siblings like browse_traits and compute_merkle_root, it stands out as the filtering tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a rate limit shared with compute_merkle_root and resolve_merkle_root, implying when to be cautious about usage. However, it does not provide explicit guidance on when to prefer this tool over siblings like browse_traits or browse_types, 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.
get_bid_recommendationARead-onlyInspect
Analyze market data and recommend a bid price range for a CryptoPunk trait selection. Combines floor price, competing bids, and set composition into actionable guidance. composition lists only the traits that define the selection; use absentTraits for a full exclusion list when needed. Rate limit: 1 per 1 min (recommend bucket).
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Type names to filter (e.g. ['Male', 'Zombie']) | |
| punkIds | No | Explicit punk IDs (overrides trait filters) | |
| matchMode | No | all | |
| excludedTraits | No | Traits to exclude | |
| includedTraits | No | Traits to include |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds behavioral context beyond that: a rate limit (1 per 1 min) and clarifies how to use `composition` vs `absentTraits`. This provides helpful usage constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description indicates the output is a bid price range, which is sufficient for a recommendation tool. The rate limit and trait selection guidelines complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), but the description adds meaningful context by explaining the difference between included traits (composition) and excluded traits (absentTraits), which aids understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool analyzes market data and recommends a bid price range for CryptoPunk trait selection. The verb 'recommend' and resource 'bid price range' are specific, and it distinguishes from sibling tools like get_floor_price or get_bids_for_punk by focusing on recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use (for trait selection) and provides a rate limit guideline. However, it does not explicitly state when not to use it or compare directly with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bids_for_merkle_rootARead-onlyInspect
Get pending EIP-712 bids matching a specific Merkle root. Useful for seeing competition on a trait-based bid set. Rate limit: 10 per 10 min (read bucket — shared with browse_types, browse_traits, get_punk_details, get_listings, get_floor_price, get_bids_for_punk).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max bids to return (default 5) | |
| merkleRoot | Yes | Merkle root (0x-prefixed, 32 bytes hex) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only. Description adds concrete rate limit (10 per 10 min) and lists which tools share the same bucket, giving agents critical operational knowledge beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then use case and rate limit. No superfluous information. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, rate limit, and parameter descriptions are in schema. Lacks return format specification, but given simplicity of tool, this is acceptable. Could optionally state that it returns a list of bids.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema with full coverage (100%). Description adds no additional semantic details about parameters, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it gets pending EIP-712 bids for a Merkle root, clearly distinguishing from sibling get_bids_for_punk which targets a specific punk. The use case of seeing competition on trait-based bids adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case ('useful for seeing competition on a trait-based bid set') and rate limit sharing with other tools, which helps agents know when to use. However, it does not explicitly list alternatives or when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bids_for_punkARead-onlyInspect
Get pending EIP-712 bids that include a specific CryptoPunk. Returns bids from the CryptoPunks Bids API. Rate limit: 10 per 10 min (read bucket — shared with browse_types, browse_traits, get_punk_details, get_listings, get_floor_price, get_bids_for_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max bids to return (default 5) | |
| punkId | Yes | Punk ID to look up bids for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds contextual behavioral details such as the rate limit (10 per 10 min) and shared read bucket with sibling tools. This provides useful operational context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the purpose, the second adds rate limit info. No fluff, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns bids but has no output schema, and the description does not explain the structure or fields of the returned bids. For a data retrieval tool, this is a significant gap that limits an agent's ability to process the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and fully documents both parameters (punkId and limit). The description does not add any additional semantic meaning or format details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves pending EIP-712 bids for a specific CryptoPunk, using a specific verb and resource. It distinguishes from siblings like get_bids_for_merkle_root and get_listings by focusing on pending EIP-712 bids via the CryptoPunks Bids API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying bids by a specific punk ID but provides no explicit guidance on when to use this tool versus alternatives like get_bids_for_merkle_root or get_bid_recommendation. No when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_floor_priceARead-onlyInspect
Get the current floor ask price from the native CryptoPunks marketplace. Excludes restricted (onlySellTo) and zero-value listings. Returns totalActive (same denominator as get_listings). Rate limit: 10 per 10 min (read bucket — shared with browse_types, browse_traits, get_punk_details, get_listings, get_bids_for_punk, get_bids_for_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so no contradiction. The description adds useful behavioral details: exclusion criteria (restricted/zero-value listings), shared rate limit bucket, and the meaning of totalActive. This exceeds the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose, then add essential details (exclusions, return field, rate limit). No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, the description fully covers what the agent needs: what it does, what it excludes, the single return field, and rate limits. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description does not need to elaborate on parameters, and it correctly provides a full explanation of the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the floor ask price from the native CryptoPunks marketplace, explicitly excluding restricted and zero-value listings. It defines the return value 'totalActive', distinguishing it from sibling tools like get_listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to get floor price) and includes rate limit information, guiding invocation frequency. While it does not explicitly mention when not to use it, the lack of parameters and simple output imply straightforward usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listingsARead-onlyInspect
Get currently listed CryptoPunks from the native marketplace. By default returns only publicly buyable listings (excludes restricted onlySellTo and zero-value entries); pass includeRestricted: true to include private bundle sales. Optionally filter by price range. Returns totalActive (publicly buyable listings, same denominator as get_floor_price) and matchedCount (after your filters). Rate limit: 10 per 10 min (read bucket — shared with browse_types, browse_traits, get_punk_details, get_floor_price, get_bids_for_punk, get_bids_for_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 50) | |
| maxPriceEth | No | Maximum price in ETH | |
| minPriceEth | No | Minimum price in ETH | |
| includeRestricted | No | Include restricted (onlySellTo) and zero-value listings. Default false — matches get_floor_price. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details default filtering (excludes private sales), the effect of includeRestricted, rate limits, and the distinction between totalActive and matchedCount counts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences, front-loaded with the primary purpose, and every sentence adds meaningful context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (totalActive, matchedCount) and provides rate limit information. It is complete for a tool with 4 optional parameters and no required inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description adds limited value for parameters. It clarifies that includeRestricted defaults false to match get_floor_price, but most parameter meaning is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves currently listed CryptoPunks from the native marketplace, specifying default behavior and optional filters. This distinguishes it from sibling tools like get_floor_price or browse_traits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool and mentions optional parameters like includeRestricted. However, it does not explicitly state when alternatives like get_bids_for_punk or use_merkle_root should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_punk_detailsARead-onlyInspect
Get metadata for specific CryptoPunks: type, traits with rarity percentages, and permalink. Rate limit: 10 per 10 min (read bucket — shared with browse_types, browse_traits, get_listings, get_floor_price, get_bids_for_punk, get_bids_for_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
| punkIds | Yes | Punk IDs to look up (1-100) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds transparency by disclosing the rate limit (10 per 10 min) and shared bucket, which is valuable beyond annotations. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and output, second states rate limit. No wasted words. Concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 1 parameter and no output schema, the description covers purpose, output, and rate limits. Could mention error behavior (e.g., invalid punkIds) but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for punkIds. The description adds meaning by specifying the output fields (type, traits with rarity percentages, permalink), which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get metadata for specific CryptoPunks' and lists specific fields (type, traits with rarity percentages, permalink). It distinguishes from sibling tools like browse_traits and browse_types which are for browsing categories, not specific IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context via rate limit and shared bucket, implying usage scenarios. However, it does not explicitly state when to use this tool versus alternatives like browse_traits or filter_punks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_merkle_rootARead-onlyInspect
Reverse-engineer a Merkle root back to its punk IDs and inferred trait selection. ONLY works for roots that already have at least one bid in the CryptoPunks Bids API — this tool looks bids up by root, then derives trait config from the resulting punk set. Returns resolved: false for unknown roots; constructing a root locally and passing it here will not work. Rate limit: 5 per 10 min (compute bucket — shared with filter_punks, compute_merkle_root).
| Name | Required | Description | Default |
|---|---|---|---|
| merkleRoot | Yes | Merkle root to resolve (0x-prefixed, 32 bytes hex) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, description reveals critical behavior: returns `resolved: false` for unknown roots, depends on external Bids API, and has compute resource rate limits shared with filter_punks and compute_merkle_root. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, constraints, and limitations. Front-loaded with the core action, each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, no nested objects), the description fully covers behavior, constraints, and rate limits. No missing information apparent for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema coverage. The description does not add significant meaning beyond the schema's pattern and description, but this is acceptable for such a simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Reverse-engineer' and resource 'Merkle root', clearly stating its function of deriving punk IDs and trait selection. It also distinguishes itself from sibling tools like compute_merkle_root by highlighting its requirement for existing bids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that it only works for roots with at least one bid in the Bids API, and that locally constructed roots will not work. Also provides rate limit context (5 per 10 min) and mentions sibling tools in the rate bucket.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!