AssetMCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool is unambiguously prefixed by its protocol (asa_, arc200_, nt200_, arc72_) and named after a specific action or query, so no two tools appear to target the same operation. Even similar functions like `balance_of` and `has_balance` have distinct meanings and clear descriptions. The grouping by asset type eliminates cross-protocol confusion.
Naming Consistency5/5
All tool names follow a strict lowercase snake_case pattern with a protocol prefix and a verb_noun or verb_txn suffix. Transaction builders consistently end in `_txn`, while queries use `get_`, `search_`, `has_`, etc., making the naming perfectly predictable across all 29 tools.
Tool Count2/5
With 29 tools, the server significantly exceeds the recommended 3-15 range for well-scoped MCP servers, and is above the 25+ threshold explicitly labeled as 'too many' in the rubric. While each tool serves a distinct purpose and covers multiple token standards, the sheer number is likely to overwhelm agents and increase selection complexity.
Completeness5/5
The tool set provides comprehensive coverage for each supported asset type: ASA queries, holdings, transfers, opt-in, and close-out; ARC-200 includes metadata, balances, allowances, approvals, transfers, and events; ARC-72 covers ownership, approvals, token URI, supply, transfers, and events. NT200 covers deposit, withdrawal, and balance box creation. Missing operations like asset creation are outside the apparent scope, so there are no critical gaps.
Average 3.5/5 across 29 of 29 tools scored. Lowest: 1.7/5.
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 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing behavioral traits. It does not state that this is a read-only operation, what it returns (boolean), or any side effects. It only names the operation, providing zero transparency about system behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It is neither front-loaded with key information nor adequately elaborated; it merely restates the function signature. While not verbose, it fails to earn its place by adding necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read query with no output schema and no annotations, the description is severely incomplete. It does not state the return format, network usage, or relationship to other ARC-72 tools. The schema provides some parameter details, but the description leaves the tool's overall behavior and invocation context largely unclear.
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 description adds no meaning beyond the schema: it echoes 'owner' and 'operator' without explaining their roles. Schema coverage is 75%, but the operator parameter lacks an explicit description, and the description does not compensate by explaining that owner is the asset owner and operator is the address being checked.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ARC-72 isApprovedForAll(owner, operator)' simply restates the tool name and parameter signature without explaining what the function does. It lacks a plain-language verb and resource, such as 'Checks whether an operator is approved to manage all assets for an owner.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like arc72_get_approved or arc72_set_approval_for_all_txn. The description gives no context about its role in the ARC-72 query family, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only restates the method name. It does not disclose that this is a read-only operation, what the return value is, whether it can revert, or any other behavioral traits, leaving the agent without critical safety and outcome information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise to the point of under-specification. It is a single fragment that adds no information beyond the tool name, so it fails to earn its place as a meaningful description.
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 tool has no output schema, so the description should explain what totalSupply() returns (e.g., an integer total supply). Without this, the description is incomplete for an agent making decisions about the invocation or handling the result. The simple parameter set is handled well by the schema, but the overall description lacks essential 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 already describes both network and appId comprehensively (including an enum for network and a description for appId). The tool description adds no parameter semantics beyond the schema, so with 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ARC-72 totalSupply().' names the standard method but doesn't explicitly state what the tool does beyond implying it calls the totalSupply function on an ARC-72 contract. It distinguishes from sibling ARC-72 tools by name but lacks a clear verb and resource description, making it minimally understandable for those familiar with ARC-72.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool instead of other ARC-72 read tools like arc72_balance_of or arc72_owner_of, nor does it indicate any prerequisites or context for invoking totalSupply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 does not mention that this is a read-only query, what the return value is, or any prerequisites (e.g., whether an approval must exist). The description is nearly silent on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than effectively concise. It lacks explanatory value and is merely a bare function reference, which does not earn its place as a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description does not explain return values, error conditions, or the distinction from related getters. For a 3-parameter tool operating on a non-trivial standard, this level of incompleteness is critically inadequate.
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 provides complete descriptions for all three parameters (appId, network, tokenId), so the baseline is 3. The description itself adds no extra parameter semantics beyond repeating tokenId, failing to enhance the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact ARC-72 operation (getApproved) and its input parameter, which distinguishes it from sibling getters like owner_of or is_approved_for_all. However, it does not explicitly state that it returns the approved address for a token, nor what 'approved' means, leaving the purpose vague for an agent unfamiliar with the ARC-72 standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related tools such as arc72_owner_of or arc72_is_approved_for_all. The description is simply a label, providing no contextual usage information.
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 should disclose behavior such as read-only nature, return values, and error handling. It only mentions 'base units', which is a small detail but does not clarify whether this is a safe query or what happens if no allowance exists.
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 extremely short and contains no superfluous words. Each phrase, including 'in base units', adds some information, but the overall brevity leads to under-specification rather than efficient clarity.
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 no output schema, the description should explain what the allowance represents and any edge cases. It only states the units, leaving the return type and behavior unspecified. Given the availability of sibling tools, this description is insufficient for an AI agent to confidently invoke it.
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 already describes appId, owner, and network (75% coverage). The description adds no information about parameters beyond listing owner and spender, which is redundant with the schema. It does not clarify parameter semantics or provide additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (ARC-200 allowance) and scope (owner, spender, base units) but lacks an explicit verb like 'get' or 'query'. It distinguishes from sibling tools by naming specific parameters, but the phrasing is more like a function signature than a statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like arc200_has_allowance or arc200_balance_of. The description does not mention any prerequisites or contrasting 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, the description must carry the full burden of behavioral disclosure. It only names the function, not its behavior—what it returns, whether it reverts for nonexistent tokens, or whether it is a read-only operation. This is a significant gap for a tool with zero 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 extremely concise—a single fragment. It is easy to parse and not bloated, but it may be too terse to stand alone without schema or external knowledge. Still, for conciseness, it earns a strong score.
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 tool has three parameters and a well-defined schema, but the description lacks context about the return value or typical use case. No output schema exists, so the description should explain what the agent should expect from the call, which it does not. Incomplete for a useful 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?
The input schema already provides complete descriptions for all three parameters (appId, network, tokenId), with 100% coverage. The description adds no parameter semantics beyond referencing tokenId, but the schema does the heavy lifting, so a baseline score of 3 is appropriate.
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 'ARC-72 ownerOf(tokenId)' clearly identifies the standard function being invoked and implies the purpose of retrieving the owner of a token. It distinguishes from siblings like balance_of or get_approved, but is terse and does not explicitly state 'get the owner address'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as arc72_balance_of or arc72_get_approved. The description does not explain the context or prerequisites, leaving the agent to infer usage solely from the name.
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 disclosing behavioral traits. It says 'simulate' and 'owner signs,' but does not clarify whether it is a read-only operation, what the output is (e.g., signed transaction), or any side effects. This is insufficient for a transaction tool.
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 clear sentence, front-loaded with the action and resource. Every word earns its place, with no filler or redundancy.
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 5-parameter transaction simulation tool with no output schema or annotations, the description is too sparse. It does not explain what the tool returns (e.g., signed transaction object), any network-specific implications, or prerequisites beyond what the schema already covers.
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 already provides descriptions for all 5 parameters with high coverage (80%+). The description adds minimal semantics by indicating the owner signs and clarifying the approve(spender, amount) relationship, but it does not significantly enhance the schema information.
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 it simulates the ARC-200 approve operation with spender and amount, and that the owner signs. This specifies the action, resource, and signature requirement, distinguishing it from sibling tools like arc200_transfer_txn and arc200_transfer_from_txn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The term 'simulate' implies it is for testing or offline transaction construction, but no exclusions or preferred scenarios are provided.
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 must disclose behavioral traits. It mentions 'simulate' and the use of arccjs directly (due to a broken wrapper), but does not clarify whether this submits a transaction or returns a simulation result, nor does it describe side effects, return values, or error conditions. This is insufficient for a transaction tool.
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 extremely concise with three short clauses, each earning its place. It front-loads the purpose, then adds an implementation note (arccjs vs broken wrapper) and a signing requirement. No wasted words.
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 transaction tool with no annotations and no output schema, the description omits critical context: what 'simulate' means (does it submit? return a signed tx?), what the return value is, and prerequisites beyond the owner signing. The high schema coverage helps with parameter semantics but does not compensate for the 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?
Schema coverage is high (80%). The description adds meaning by naming operator and approved in the method signature and noting 'Owner signs' for the owner parameter, but it does not elaborate on appId or network. This is consistent with the baseline 3 for high schema coverage with marginal extra 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 names the exact ARC-72 method (setApprovalForAll) with its parameters, clearly distinguishing it from siblings like arc72_approve_txn (single-token approval) and transfer tools. The verb 'Simulate' plus the resource and parameter list makes the purpose specific and unambiguous.
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 granting/revoking operator approval over all tokens, but does not explicitly contrast with alternatives such as arc72_approve_txn. The 'Owner signs' note adds some context, but there is no clear when-to-use vs when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the output is a UTF-8 string and that null bytes are stripped by ulujs, which is useful. However, it omits any error behavior, network requirements, or what the URI string represents in practice.
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 one concise, front-loaded sentence that conveys the essential function and output type without any redundancy. Every part adds value.
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 provides enough to know the return type (UTF-8 string) and the core operation, but it lacks details on why to use this over sibling metadata tools, possible error conditions, or how the URI relates to on-chain metadata. For a simple getter with no output schema, it is minimally adequate but leaves gaps.
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% coverage, describing all three parameters (network, appId, tokenId) with clear meanings. The description adds no additional parameter semantics beyond referencing tokenId in the function signature, so the baseline of 3 is appropriate.
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 it retrieves the ARC-72 tokenURI for a given tokenId, returning it as a UTF-8 string. This distinguishes it from sibling tools like arc72_owner_of or arc72_balance_of, and the method name 'tokenURI' is a specific action on the token resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like arc72_get_metadata, which may be more appropriate for broader metadata. The description does not mention any exclusions or preferred contexts.
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 only states 'Load', which implies a read operation, but does not clarify potential error behavior, network dependency, or output format. The mention of 'Algod' hints at the underlying API but does not explain any side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose. It contains no unnecessary words or repetition, making it highly concise and easy to parse.
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 with only two parameters, and the description adequately conveys the core purpose. However, with no output schema and no additional context, the agent lacks information about the return structure or any edge cases, so the description is minimally sufficient but not complete.
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 already covers 100% of the parameters with descriptions for assetId and network. The description adds no new meaning beyond saying 'by asset ID', which is already in the schema. Since schema coverage is high, a baseline score of 3 is appropriate.
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's function with a specific verb ('Load') and resource ('ASA configuration and on-chain parameters'), and specifies the method ('by asset ID'). It distinguishes itself from sibling tools like asa_get_holding or asa_search_holdings by focusing on the asset definition rather than holdings or searches.
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 a use case (retrieving a single asset's configuration by ID) but does not explicitly state when to use this tool over alternatives. There is no mention of exclusions or comparisons with related tools, leaving the usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses that the return is 'base units (string in response)', which is useful, but it does not explicitly state that the call is read-only, mention any side effects, or describe error conditions. This is minimal but non-trivial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and the key clarification (base units, string response). Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema fully documents its parameters. The description adds the return format and units, which is helpful given the lack of an output schema. However, it omits any comparison to sibling tools or edge case behavior, leaving a small gap 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?
The schema already provides descriptions for all three parameters (appId, address, network) with 100% coverage. The description does not add parameter-level meaning beyond what the schema offers. The 'base units' note clarifies the return rather than the parameters, so the baseline score of 3 is appropriate.
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 specifies the action (ARC-200 balanceOf) and the resource (a specific token holder on an ARC-200 contract). It distinguishes itself from siblings by naming the standard and noting 'base units' for the return, which is a unique characteristic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like arc200_has_balance or arc72_balance_of. The description does not provide context for selection or exclude cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses the underlying mechanism ('via indexer') and names the library ('ulujs getEvents'), which helps the agent understand this is an off-chain, read-oriented query. However, it does not explicitly state the read-only nature, return format, or indexer consistency limitations, leaving some behavioral ambiguity.
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 11-word sentence that front-loads the action and object. It contains no filler, is immediately scannable, and every word earns its place. The parenthetical event types and implementation note are compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description is too sparse to be fully complete. It doesn't describe the return value shape (e.g., a list of event objects with fields like name, args, transaction ID), nor explain how the round/address filters combine. The 'ulujs getEvents' reference implies a known format but doesn't expose it to the 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific detail beyond what the schema already documents; it doesn't explain how 'limit', 'address', or round filters affect event fetching. The 'Transfer + Approval' mention hints at which event types are filtered but doesn't add meaningful parameter 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 the specific verb 'Fetch' with resource 'ARC-200 contract events' and enumerates event types ('Transfer + Approval'). It distinguishes from sibling arc72_get_events by explicitly limiting to ARC-200, and the 'via indexer' note adds operational context. The only minor caveat is that the input schema's appId property references ARC-72 as well, but the description itself is unambiguous.
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 the tool is for retrieving ARC-200 event data but provides no explicit when-to-use guidance or alternatives. It does not mention that arc72_get_events should be used for ARC-72 contracts, nor any caveats about preferring balance/allowance queries for specific state checks. This is minimal implicit usage guidance, not a clear directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels this as a 'read' operation and specifies the check condition (box present / non-zero). However, it does not explain the return format (likely boolean) or any edge-case behavior. Since no annotations are provided, the description carries the burden, and it partially meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence and front-loaded with the core behavior. The 'ulujs dual-schema read' phrase adds some jargon but does not overwhelm. It earns a 4 for efficient structure.
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?
No output schema or annotations exist, so the description should clarify return values and safety. It hints at a boolean check but does not explicitly state the return type. Given the tool's simplicity, this is adequate but with gaps.
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 already covers owner and spender as addresses, and network/appId are documented. The description only names the expected parameters in a function signature, adding minimal semantic detail beyond the schema. With 75% schema coverage, the baseline is 3.
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 checks whether an allowance box is present and non-zero for a given owner/spender pair. This distinguishes it from sibling arc200_allowance which would return the allowance value itself.
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?
Usage context is implied by the phrasing 'hasAllowance' and the distinction from allowance tools, but there is no explicit when-to-use or alternative guidance. The description does not mention alternatives or exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the tool 'simulates' a transfer and returns an 'unsigned' txn group, meaning no on-chain effect occurs and the result must be signed externally with UluWalletMCP. This is valuable context, though it does not address error cases or prerequisites.
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, compact sentence that front-loads the core action and output format. It contains no redundant or filler words, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description's mention of 'unsigned txn group as base64 strings' provides essential return-format information. It also hints at the next step (signing with UluWalletMCP). However, it does not describe the structure of the returned group or mention that the appId may be an ARC-72 contract as noted in the schema, leaving minor gaps for a moderately complex 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?
The input schema already provides descriptions for all 5 parameters, achieving 100% coverage. The tool description adds no parameter-specific meaning beyond the schema. It does not clarify base-unit amounts or the requirement that the sender sign, but those are already covered in the schema, so the description meets the baseline.
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 a specific action and resource: 'Simulate ARC-200 transfer' and return an unsigned txn group as base64 strings. It distinguishes from read-only ARC-200 tools by its transaction-building nature, but it does not explicitly differentiate from the sibling arc200_transfer_from_txn, relying on the naming convention and schema fields (sender/receiver) to imply a direct transfer.
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 explicit guidance on when to use this tool versus alternatives such as arc200_transfer_from_txn or arc200_approve_txn. The only hint is 'sign with UluWalletMCP', which implies a signing workflow, but there are no clear conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Simulate' discloses that the tool does not execute a real transaction, and 'owner signs' indicates a required signer. However, with no annotations, remaining behavioral traits are unclear: what is returned (simulation result?), whether any state is changed, and if network specifics or prerequisites exist. The description adds some value but leaves significant 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 compact sentence, front-loaded with the action and key parameters. Every word earns its place with no redundancy or filler.
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?
While the schema is rich, the description fails to explain what the tool returns (no output schema), how it differs from arc72_set_approval_for_all_txn, and what 'simulate' means concretely in terms of execution. For a transaction-related tool with no annotations, this is insufficient context for an agent to confidently select and invoke it 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?
Schema coverage is 100%, so all parameters are already fully described. The description repeats 'approved' and 'tokenId' from the function signature but adds no new semantic detail beyond the schema. Baseline of 3 is appropriate.
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 states a specific verb 'Simulate' and a specific resource 'ARC-72 approve(approved, tokenId)', making it clear this simulates a single-token approval. It naturally distinguishes from siblings like arc72_set_approval_for_all_txn (which approves for all tokens) and arc72_transfer_txn (which transfers ownership).
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 single-token approval but doesn't explicitly contrast with alternatives like set_approval_for_all. No when-to-use or when-not-to-use guidance is provided, but the function signature in the description strongly suggests the intended scenario.
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 must disclose safety and behavior. It implies a read-only operation through 'balanceOf' but does not mention edge cases, error conditions, or whether state is modified. This is a gap for an unannotated tool.
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, well-structured sentence that is front-loaded with the method name and conveys the essential meaning without wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of this query tool and complete schema coverage, the description is adequate for most purposes. It could mention return format or error behavior, but the description's clarity and the schema's completeness make it mostly complete.
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 describes all three parameters fully (100% coverage), including address format and network enum. The description adds no new parameter semantics beyond highlighting the address parameter in the method signature, so the baseline score of 3 applies.
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 specifies the exact operation (balanceOf) and the result (number of NFTs owned) for ARC-72, clearly distinguishing it from sibling tools like arc72_owner_of or arc72_total_supply.
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 via the function name and result, but does not explicitly state when to choose this over alternatives like arc200_balance_of or arc72_owner_of, nor any exclusions. Usage context is clear but not elaborated.
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 only states it 'fetches' events, but does not disclose return formats, pagination behavior, or potential limitations such as indexer dependencies or ordering. The parenthetical 'ulujs getEvents' hint is sparse and adds little context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and target. It avoids unnecessary words and front-loads the core purpose, making it easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description should provide more context about how the tool behaves, such as what the event list looks like, how pagination works, or parameter interactions. The current description is minimal and leaves significant gaps for a tool with this complexity.
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 provides detailed descriptions for all 8 parameters (100% coverage), so the baseline is 3. The description itself adds no parameter-specific meaning, but the schema fully documents each field, including filters like txid, round, and address.
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 fetches ARC-72 Transfer, Approval, and ApprovalForAll events, using a specific verb and resource. This distinguishes it from sibling tools like arc200_get_events because it explicitly names the ARC-72 standard and event types.
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 makes it clear this tool is for retrieving ARC-72 event logs, providing context for when an agent would use it. However, it does not explicitly mention alternatives or exclusions, such as 'use arc200_get_events for ARC-200 contracts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two key behaviors: the transaction is unsigned and involves a 0-amount self transfer. With no annotations provided, it carries the full burden, but it omits details like return format, signing requirements, or side effects. It provides some insight but not comprehensive transparency.
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, focused sentence with no redundant words. It is front-loaded with the core action and includes the clarifying parenthetical, making it highly concise and efficient.
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 transaction builder with 4 well-documented parameters, the description is adequate but minimal. It lacks explicit mention of the return value (though 'build' implies an unsigned transaction) and provides no usage context beyond the basics. Given no output schema, the description should do more to explain the output, but the current text meets the minimum viability.
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?
All 4 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter-specific meaning, which is acceptable since the schema already documents sender, assetId, network, and note sufficiently.
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's purpose: to build an unsigned ASA opt-in transaction, specifying the verb 'build' and the resource 'ASA opt-in'. It also clarifies it's a 0-amount self transfer, distinguishing it from transfer and closeout transaction builders.
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?
Usage is implied: the tool is for opting into an ASA. However, there is no explicit guidance on when to use this instead of asa_transfer_txn or asa_closeout_txn, nor any prerequisites or exclusions. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation is paginated and performed via Indexer, which are useful behavioral traits. However, it does not explicitly state that it is read-only, nor does it describe response structure or potential errors. The 'List' verb implies a read operation, but more context would be helpful.
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, front-loaded sentence that covers the core action (list), resource (holdings), scope (account), method (Indexer), and key option (assetId filter). Every word contributes, with zero waste.
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 absence of an output schema, the description does not explain the return format or how to use pagination tokens (nextToken), which are important for consumption. It provides the essential context but leaves the agent to infer details about the response structure and pagination flow, making it minimally complete.
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 80% (4 of 5 params have descriptions), matching the high coverage baseline of 3. The description adds minimal value beyond the schema: it mentions 'Optional assetId filter' but the schema already explains this. No additional parameter meaning is 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 uses a specific verb ('List') and resource ('ASA holdings for an account'), clearly conveying the tool's function. It distinguishes from sibling tools like asa_get_holding by emphasizing the list/search nature, and it adds method context ('via Indexer') and pagination.
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 (list holdings, optionally filter by assetId) but does not explicitly state when to choose this tool over alternatives like asa_get_holding. It lacks direct 'when to use' vs 'when not to use' guidance, but the context is somewhat clear from the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates a read operation and mentions 'ulujs + simulation', hinting at simulation-based execution, but does not detail return format, error conditions, or non-mutating guarantees beyond the verb 'Read'.
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 concise sentence that front-loads the core purpose and lists return fields. The only extra descriptor 'ulujs + simulation' is compact but potentially cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lists the return fields (name, symbol, decimals, totalSupply), which is helpful given there is no output schema. However, it lacks context about the simulation behavior and does not address error cases or prerequisites, leaving some gaps.
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 already provides 100% description coverage for both network and appId parameters. The tool description adds no parameter-specific details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Read ARC-200 name, symbol, decimals, and totalSupply', specifying a verb, resource, and exact data fields. The mention of ARC-200 distinguishes it from sibling arc72_get_metadata.
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?
No explicit when-to-use or alternative guidance provided. The tool's purpose implies it is for retrieving standard token metadata, but it does not contrast with balance or allowance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Return' and 'Algod account info' suggest a read-only query, but the description does not explicitly state that it has no side effects, nor does it disclose any error conditions, authentication needs, or rate limits. It provides basic transparency but lacks depth.
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, front-loaded sentence: 'Return one account's balance and frozen flag for an ASA (Algod account info).' Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 required parameters, no output schema), the description adequately communicates the return value (balance and frozen flag). It does not specify the exact output format or types, but for a straightforward getter, the high-level return fields are sufficient. It is slightly less complete because it doesn't state any caveats or edge cases, but overall it is adequate.
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 100% with clear parameter descriptions (Account to inspect, ASA asset ID, network). The description adds only the contextual phrase 'one account's balance', which reinforces the singular scope but does not add semantic information beyond the schema. Baseline 3 is appropriate.
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?
'Return one account's balance and frozen flag' is a specific verb+resource phrase. The phrase 'one account's' clearly distinguishes it from asa_search_holdings (likely multiple accounts) and asa_get_asset (asset info vs holding info). The description fully identifies what the tool does.
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 a singular use case ('one account's'), but does not explicitly state when to use this tool versus alternatives like asa_search_holdings or asa_get_asset. No explicit 'when not to use' guidance is provided; usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly labels this a 'read' operation, indicating it is non-mutating, and clarifies the semantic of 'has balance' as checking for a non-zero balance box. However, it introduces vague jargon 'ulujs dual-schema' without explanation and does not disclose return type 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with the function name. However, the phrase 'ulujs dual-schema read' is cryptic and may confuse rather than clarify, slightly reducing its structural effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean read operation, the description covers the core behavior ('whether the account has a non-zero balance box') and is sufficient given the schema fully documents inputs. It does not explicitly state the return value, but the phrasing implies a boolean result. No output schema exists, so a bit more detail would improve 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 coverage is 100%, with all three parameters (network, appId, address) described. The description adds no extra parameter-level detail beyond mentioning 'address' in the function signature, so it provides no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether an account has a non-zero balance box via the ARC-200 hasBalance function. It distinguishes itself from siblings like arc200_balance_of by focusing on the existence of a balance rather than the amount.
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 is a read-only query for verifying balance box existence, but it does not explicitly mention alternatives or when not to use it. Sibling context suggests balance_of for amounts, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses that this is a simulation and that the spender signs, which is useful behavioral context. However, it does not clarify what the tool returns (e.g., a transaction object, simulated result) or whether it has side effects, leaving significant ambiguity for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the operation, signature, and signing party without wasted words. It is fully front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction-simulation tool with no output schema, the description gives the core purpose and signature but omits details about the return value or side effects. Despite being brief, it is adequate for an agent to understand the tool's role, though it could be enriched with more 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 descriptions cover most parameters (83%), and the description adds minimal new meaning beyond the signature. It reinforces that spender is the signer and lists params in order, but does not explain roles like 'from' being the source and 'to' the destination beyond what the function name implies. Baseline 3 is appropriate given high schema coverage.
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 verb 'simulate' and the resource 'ARC-200 transferFrom', including the function signature (spender, from, to, amount) and who signs. It effectively distinguishes this from sibling tools like arc200_transfer_txn by naming the specific operation.
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 use case: when simulating a transferFrom with spender authorization. However, it does not explicitly compare with alternatives such as arc200_transfer_txn or arc200_approve_txn, nor does it state when not to use this tool. The context is clear from the function name but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses two important behavioral traits: the transaction is 'unsigned' (so not submitted) and closeRemainderTo will close the sender's holding. It does not mention potential side effects like address validation, balance checks, or error behavior, which leaves some gaps for a transaction builder.
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, front-loaded with the core action and followed by key clarifications. Every sentence earns its place, with no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction builder with seven parameters and no output schema, the description covers the essential: what it builds, the unit of amount, and the close behavior. It implicitly communicates that the return is an unsigned transaction object, though it does not explicitly describe return format or error cases. Given the complexity, this is adequate but could be slightly more explicit.
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 86%, so the description does not need to compensate much. It adds the clarification that amount is in base units and that closeRemainderTo closes the sender holding, but these are already stated in the schema properties. The description adds minimal value beyond the schema, so the baseline score of 3 is appropriate.
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 'Build' and identifies the resource as an 'ASA transfer (axfer)', which precisely names the operation. It clearly distinguishes this from sibling tools like asa_optin_txn and asa_closeout_txn, and the parenthetical '(axfer)' roots it in the Algorand transaction type.
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 clearly implies the use case: building a transfer transaction for an ASA. However, it does not explicitly provide when-not-to-use guidance or name alternatives (e.g., 'for closing out, use asa_closeout_txn instead'). The context is clear enough for an agent to select this tool among ASA-related builders.
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?
With no annotations provided, the description carries the transparency burden. It discloses that the output is unsigned transactions and describes the transaction structures (payment+app call or axfer+app call). It does not mention side effects or dependencies, but the key behavior is covered.
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 short and front-loaded with the primary purpose. There is minor redundancy between the second and third sentences, and the final note about 'ulujs CONTRACT + abi.nt200' is cryptic, slightly reducing 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 tool with no output schema and no annotations, the description covers the main behavior but omits practical details like return type, grouping expectations, and prerequisites such as opt-in or balance box requirements. This leaves some gaps for an AI 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the schema, only reiterating the assetId conditional behavior that the schema already explains.
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 it builds unsigned NT200 deposit transactions, specifying the two modes (network token or ASA) and the transaction sequencing. This distinguishes it from sibling tools like nt200_withdraw_txn or arc200_transfer_txn.
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?
Provides clear context for when to use each mode ('set assetId for axfer' vs. network token) and notes the deposit precedes an app call. However, it does not explicitly contrast with alternatives or mention when not to use this tool.
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?
With no annotations provided, the description carries the behavioral transparency burden. It discloses that the transaction is unsigned, that it sets closeRemainderTo to close the holding, and that the amount must be the full balance. This covers key behavioral traits without contradiction.
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, front-loaded sentence that conveys the core purpose and a critical usage constraint without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains the tool's main effect (closing an ASA holding), the required amount behavior, and the transaction type. The schema fills in parameter details. It could be slightly more explicit about the consequences of not supplying the full balance, but overall it is complete for a transaction builder.
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 has 100% coverage and all parameters have descriptions, so the baseline is 3. The description adds a helpful global note about supplying the full balance as amount, but this aligns with the schema's 'Whole balance to move in base units.' No additional parameter-level meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an unsigned ASA transfer that closes the sender's holding via closeRemainderTo, distinguishing it from a standard asa_transfer_txn. It uses specific verbs and resources ('closes the sender's holding') and is unambiguous about its unique purpose.
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 this tool: to close out an ASA holding entirely. It provides clear context with 'closes the sender's holding' and instructs to 'supply full balance as amount,' which is a crucial usage guideline. It does not explicitly name alternatives, but the sibling tool set makes the distinction evident.
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?
With no annotations, the description itself discloses that the tool builds unsigned transactions, may include a payment transaction, and only acts when the box does not already exist. It also reveals the underlying 'ulujs CONTRACT + abi.nt200' dependency, adding behavioral context beyond the schema.
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?
Three short sentences front-load the core purpose and then add necessary behavioral details. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description conveys the key facts: the tool returns unsigned transaction(s) for creating a balance box, may include payment, and is conditional on box existence. It could mention the exact return structure, but for a simple txn builder this is adequate.
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 covers all four parameters with descriptions (100% coverage), so the description does not need to explain parameter mechanics. It confirms 'specified address' and 'box creation cost' but adds no syntax beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific operation ('Build unsigned NT200 createBalanceBox(address) txn(s)') and explains its effect ('Creates a balance box...'), which clearly differentiates it from sibling transaction builders like nt200_withdraw_txn or nt200_deposit_txn.
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?
It states the condition under which this tool is relevant ('if it doesn't exist') and notes that it may include a payment txn for creation cost. It does not explicitly name alternatives or exclusions, but the context is clear enough for selection among the NT200/ARC200 siblings.
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?
With no annotations, the description conveys that the tool builds an unsigned transaction (no immediate side effects), supports specific asset types, requires opt-in, and produces a single transaction. This goes beyond the schema but could mention more about the returned object or failure modes.
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 three sentences long, front-loaded with the core action, and every sentence provides useful information: the action, the assets, the prerequisite, and the transaction structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering no output schema, the description implies the return value (an unsigned transaction) and includes key context (asset types, opt-in requirement, single txn). It is sufficient for selection but could benefit from stating the return format or edge cases.
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 already covers all parameters with descriptions (100% coverage). The description adds minimal per-parameter detail beyond naming 'amount' in the function call, so it meets the baseline but does not enrich beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an unsigned NT200 withdraw transaction, specifies the action (withdraw), the resource (ARC-200 wrapped network tokens or ASAs), and distinguishes it from sibling tools like nt200_deposit_txn and arc200_transfer_txn.
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?
It provides clear context for use (withdrawing/unwrapping) and a prerequisite (token holder must be opted in). It does not explicitly mention alternatives or when not to use it, but the context and sibling names make the intended usage clear.
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?
With no annotations, the description carries the behavioral burden. It explicitly states 'Simulate,' indicating non-execution, and specifies the signer requirement, which are key safety and context details. It does not explain return values or side effects further, but covers the most critical behaviors.
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 short sentences, front-loaded with the core action, and every word adds value. No filler or redundant repetition of schema details.
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 lack of an output schema, the description does not explain what the simulation returns (e.g., transaction object, success status, error details). It provides a high-level purpose but leaves a gap in understanding the tool's output behavior, making it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, but the description adds meaning beyond the schema by clarifying the relationship between 'sender' and 'from' (sender must be the owner or approved operator). This helps the agent understand authorization without relying solely on field descriptions.
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 ARC-72 transferFrom(from, to, tokenId), using a specific verb and resource. It distinguishes from sibling tools by naming the exact function and clarifies the signer 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 when to use this tool: to simulate a transferFrom transaction, and clarifies authorization (sender must be owner or approved operator). However, it does not explicitly mention alternatives or exclusion cases like when to use approval tools instead.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states conditional behavior (owner/tokenURI/approved only if tokenId is set) and optional behavior (supportsInterface selector), which goes beyond the schema. However, it does not explicitly state that the operation is read-only or describe error handling, but 'facts' strongly implies a non-mutating query.
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, well-structured sentence that front-loads the core purpose and packs all essential conditional logic with minimal words. Every part earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the core behavior, parameter semantics, and conditional logic well. It might be slightly stronger with an explicit note about return format or behavior when tokenId is absent, but the provided facts list makes the expected output clear enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds valuable semantic context by explaining how tokenId controls which fields are returned and clarifies that interfaceSelectorHex is an 8-hex selector. This meaningfully supplements the schema's individual parameter descriptions.
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 'Aggregate' with resource 'ARC-72 facts', and immediately lists the exact data returned (totalSupply, owner, tokenURI, approved, supportsInterface). This clearly distinguishes it from sibling tools like arc72_total_supply or arc72_owner_of by presenting a combined, conditional query.
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 effectively communicates when to use this tool: when you need multiple ARC-72 metadata facts in one call. It implies a read-only aggregation use case but does not explicitly contrast it with alternatives or state when not to use it (e.g., if you only need totalSupply, use arc72_total_supply).
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:

[![AssetMCP MCP server](https://glama.ai/mcp/servers/NautilusOSS/AssetMCP/badges/card.svg)](https://glama.ai/mcp/servers/NautilusOSS/AssetMCP)

Score Badge

Copy to your README.md:

[![AssetMCP MCP server](https://glama.ai/mcp/servers/NautilusOSS/AssetMCP/badges/score.svg)](https://glama.ai/mcp/servers/NautilusOSS/AssetMCP)

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/NautilusOSS/AssetMCP'

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