OpenZeppelin Contracts MCP Server

Official

by OpenZeppelin

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.8
Disambiguation3/5
Most tools are distinct by platform+template, but there is real overlap risk: `solidity-erc20`, `stylus-erc20`, and `cairo-erc20` have near-identical descriptions and differ only by prefix. The repeated template wording across Solidity, Cairo, Stylus, and TRON forces agents to rely on the name rather than the description.
Naming Consistency4/5
The overwhelming pattern is lowercase `platform-template` (e.g., `cairo-governor`, `tron-trc20`, `stellar-vault`), which is very predictable. Minor deviations exist: `uniswap-hooks` and `confidential-erc7984` omit the `solidity-*` prefix even though both target Solidity.
Tool Count3/5
33 tools is on the heavy side, but the server covers multiple smart-contract ecosystems and each tool maps to a distinct contract template, so the count is understandable. Still, the surface feels broad and could be streamlined with parameterized generation tools.
Completeness3/5
Core token, governance, account, and custom generators are broadly represented across ecosystems, but coverage is uneven: Cairo has vesting, multisig, and ERC-6909 while Solidity lacks similar vault/vesting generators, and Stylus and Stellar have no `custom` fallback. Most common workflows are covered, but platform parity is incomplete.
Average 3.8/5 across 33 of 33 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 commits in the last 12 weeks
- Last stable release on September 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It states the tool returns Markdown-formatted source code and does not write to disk, which are important side-effect facts. However, it doesn't disclose other behaviors like network calls, compilation, or whether it's purely deterministic. For a code-generation tool, the disclosed behavior is adequate but not exhaustive.
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: two short sentences with no filler. It front-loads the core purpose and then states the two most operationally relevant behaviors (output format and no disk write). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 13 parameters, nested objects, and no output schema, the description is minimal. It does not explain how to choose this tool over near-identical siblings (e.g., solidity-erc1155 or cairo-erc721), nor does it hint at what a successful response contains beyond a code block. The schema covers parameter details, but the description lacks usage context and integration guidance, making it insufficient 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?
Schema description coverage is 92%, so the schema documents most parameters. The description adds no parameter-specific meaning beyond what the schema already provides. It does not explain how the numerous boolean flags interact or what the nested objects control, but the high coverage makes the schema the primary source. Baseline 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 clearly states it creates an ERC-1155 non-fungible token and returns source code. The verb 'Make' is specific, and the resource (ERC-1155 standard) is clear. It distinguishes from ERC-20/ERC-721 siblings, though it doesn't explicitly say this is for Cairo (relying on the tool name).
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 solidity-erc1155 or cairo-erc721. There is no mention of context, prerequisites, or exclusions. The description does not help an agent decide between this and sibling code generators.
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 usefully discloses that the tool does not write to disk and returns source code in a Markdown code block, which addresses safety and output format. However, it does not mention other behaviors like execution time, dependencies, or failure modes, which would be valuable for a complex generator.
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 concise: two sentences, front-loaded with the core purpose and immediately clarifying output format and lack of side effects. Every sentence earns its place without 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?
Despite having a rich schema, the description lacks high-level context about the generated contract's capabilities (e.g., voting, timelock, upgradeability). It does not clarify that this is Cairo-specific or how it relates to the solidity-governor sibling. No output schema or annotations further burden the description, which falls short for a complex tool with 17 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 17 parameters, so the description does not need to add parameter explanations. The baseline of 3 applies; the description adds no parameter context beyond what the schema already provides.
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 states a clear action: generate a governance contract (e.g., for a DAO). However, it does not explicitly distinguish itself from sibling tools like solidity-governor; the Cairo-specific nature is only implied by the tool name, not described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives, such as solidity-governor or other contract generators. It only states what the tool does, with no mention of use cases, prerequisites, or when it would be inappropriate.
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 disclosure burden. It clearly states that the tool returns source code in a Markdown code block and does not write to disk, which are important side-effect details for an agent. It omits deeper information about edge cases or errors, but the core behavior is transparent.
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 concise sentences that front-load purpose and immediately state return format and side-effect behavior. Every sentence earns its place with no filler.
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 highly parameterized tool with 18 inputs and no output schema, the description is minimal but does cover the key return value and side-effect profile. It does not compensate for the absence of annotations or explain how the generator fits among sibling Solidity/Cairo/stylus tools, leaving the context incomplete.
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 rich per-parameter descriptions already carry most of the semantic weight. The tool description itself adds little about parameters beyond 'per the ERC-20 standard', so it meets the baseline but does not go further.
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 says 'Make a fungible token per the ERC-20 standard', which is a clear verb plus resource, and the title/name make the Solidity context obvious. However, it does not explicitly distinguish itself from siblings such as solidity-stablecoin, solidity-rwa, or cairo-erc20.
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 about when to use this tool versus the many sibling generators. The description does not state alternatives, exclusions, or prerequisites, so an agent must infer usage from the tool name alone.
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?
Given the absence of annotations, the description carries the full burden and does a good job: it states the tool does not write to disk and returns source code in a Markdown block. The experimental, unaudited nature of some features is disclosed multiple times in the schema, and while the description mentions it, the specifics about which features are experimental are only in the schema. The description is honest that some features are experimental and subject to change, providing critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and to the point, consisting of only three sentences that efficiently convey the core purpose and critical experimental caveat while front-loading the main value proposition.
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 highly complex tool with 19 parameters and nested objects, the description is quite minimal. The schema and parameter descriptions are rich, but the description does not explain the overall workflow or the contract's architecture, nor does it provide an overview of what the generated code looks like. No output schema exists to fill in gaps, so the description could have been more complete about the tool's overall behavior, making its output a contract source file.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the baseline is 3, but the description adds zero information about how parameters shape the generated contract. With 19 parameters, the description's silence on how the schema parameters configure the output and the impact of those choices is a miss. The description also doesn't clarify the meaning of higher-level interactions like votes and crossChainBridging or the tradeoffs, though the schema itself is thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool makes an ERC-20 real-world asset token, though the term 'real-world asset token' is a bit unusual and could benefit from more specificity. The description differentiates it as experimental and clarifies the output is source code in a Markdown block, which helps distinguish it from sibling tools like solidity-erc20 by focusing on the real-world asset aspect.
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 when the user wants to create an ERC-20 RWA token, but does not explicitly explain when to choose this over siblings like solidity-erc20. No alternative tools are named, and the differences are left implied. The experimental warning provides some context for when caution is needed, but it is minimal.
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 full burden. It explicitly states that the tool returns generated source code as a Markdown code block and does not write to disk, which are crucial behavioral details. It also warns that the tool is experimental. Minor gaps remain around error conditions or output characteristics.
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 highly concise and front-loaded, stating purpose and major caveat in the first sentence, then returning behavior in a compact second paragraph. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (19 parameters, nested objects, no output schema), the description is adequate but sparse. It covers output format and non-persistence, and the schema covers parameters, but it omits an overview of how stablecoin-specific options relate to the tool's purpose and how this tool compares to sibling ERC-20 generators.
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 tool description itself adds no parameter-level meaning; it relies entirely on the schema for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating a stablecoin token using the ERC-20 standard. However, it does not differentiate from sibling tools like solidity-erc20 or solidity-custom, missing the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as solidity-erc20 or solidity-rwa. Prerequisites, exclusions, and trade-offs are not mentioned; the experimental warning is a caveat, not usage direction.
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 effectively discloses key behaviors: returns source code, formats it as a Markdown code block, and does not write to disk. This clarifies side effects and output expectations, which is especially valuable for a code generation tool. It does not mention other potential side effects or prerequisites, but for this tool's simplicity, the disclosure is sufficient.
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 concise and well-structured, with two short sentences that immediately state the purpose and then clarify the output format. Every sentence earns its place, and there is no unnecessary detail.
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 schema fully documents parameters, and the description covers output format and side effects. However, it lacks any context about the Stylus framework or guidance on when to choose this over other ERC-20 generators, which is a notable gap given the rich sibling list. Overall, it is sufficient for a straightforward generator but not complete in terms of usage 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 provides thorough descriptions for all 5 parameters, covering 100% of them. The description itself adds no additional parameter semantics or usage tips, so it meets the baseline for complete schema coverage without exceeding it.
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 'Make a fungible token per the ERC-20 standard,' which identifies the specific verb and resource. It distinguishes from sibling tools that target other standards (e.g., ERC-721, ERC-1155), though it omits explicit mention of the Stylus/Rust framework, relying on the tool name.
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 solidity-erc20 or cairo-erc20. There are no exclusions or alternative recommendations, leaving the agent to infer the appropriate context 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses key behavior: returns source code formatted in a Markdown code block and does not write to disk. This is important for understanding side effects and safety. It doesn't mention dependencies or network usage, but it's a code generator so the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, roughly 50 words, and front-loaded with the purpose. The second paragraph provides essential behavioral details (return format, no disk write). Every sentence contributes meaning, with no unnecessary 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 code generator with 9 params and no output schema, the description provides essential context: what the tool generates, the return format, and its non-persistent nature. The schema covers all parameters individually. The description doesn't explain parameter combinations, but that's not required given the rich schema. It is adequately complete for common use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a clear explanation. The tool description adds no parameter-level meaning, but the schema does the heavy lifting. Baseline 3 is appropriate; the description neither enhances nor contradicts the schema.
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 uses a specific verb 'Make' and clearly identifies the resource: a custom smart contract representing an account. It explains the purpose (validate and execute transactions) and returns generated source code. While it doesn't explicitly distinguish from sibling account generators (e.g., solidity-account), the Cairo context is evident from the tool name.
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 explicit when-to-use or when-not-to-use guidance is provided. The description states the tool can be extended for custom logic but does not mention alternatives or exclusions. Given many sibling code generators exist, this lack of guidance makes selection harder for an AI agent.
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 and does usefully disclose that the tool returns source code in a Markdown block and does not write to disk. It does not discuss other side effects or execution behavior, but the key non-destructive behavior is explicit.
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 with no filler: the first states the core purpose and the second states output format and side-effect behavior. Every sentence earns its place and the key information is front-loaded.
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 rich input schema and lack of an output schema, the description adequately covers what the agent needs to know about the return value and side effects. It could be more explicit about the Cairo language/platform, but the tool name and title already supply that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 93%, so the schema already documents the parameters and the description adds no additional parameter-level meaning. The baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and deliverable: it makes a fungible token per the ERC-20 standard and returns contract source code. It distinguishes from non-ERC-20 siblings, but it does not explicitly mention Cairo, leaving some ambiguity among the multiple ERC-20 siblings in different languages.
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 offers no guidance on when to use this tool versus alternatives such as solidity-erc20, tron-trc20, or stylus-erc20. It explains output behavior but not selection criteria, prerequisites, 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 behavioral burden. It does this well by disclosing the output format ('formatted in a Markdown code block') and explicitly stating 'Does not write to disk,' which clarifies the tool is a non-persistent source-code generator. It does not cover behavior on invalid or conflicting parameters, but the core side-effect profile is transparent.
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 with no filler: it front-loads the purpose, then states the return format and side-effect behavior. Every sentence adds distinct value.
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 code-generation tool with a rich input schema and no output schema, the description supplies the missing pieces: return format and lack of disk writes. It does not explicitly mention the target chain/language in the description, but the tool name and title cover that context. All functional parameters are already explained in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (94%), so the input schema already provides strong parameter-level meaning. The description adds no parameter-specific details, which is acceptable under the high-coverage baseline of 3.
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 uses a specific verb and resource: 'Make a non-fungible token per the ERC-721 standard,' and clarifies that it returns contract source code. It distinguishes the tool from ERC-20/ERC-1155 siblings by naming the standard, though it does not explicitly state 'Cairo' or reference sibling Solidity/Stylus ERC-721 tools, leaving some differentiation to the tool title/name.
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 about when to use this tool versus alternatives such as solidity-erc721, stylus-erc721, or cairo-erc1155. No conditions, exclusions, or explicit alternative selection hints are provided; usage is only implied by the tool name and the ERC-721 standard mention.
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 disclosing safety and side-effect behavior. It explicitly states 'Does not write to disk' and 'Returns the source code... in a Markdown code block', providing crucial non-persistence and output format information. However, it doesn't mention other potential behaviors like network access or validation, so it stops short of being fully transparent.
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 and front-loaded with the core purpose. The second sentence adds essential behavioral details (output format and non-persistent nature) with zero waste. 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 having 11 parameters and no output schema, the description provides a clear statement of the return value (source code in Markdown) and the non-disk-writing behavior. The schema handles parameter details. The main gap is a lack of context about how parameters influence the generated contract, but the schema descriptions mitigate this. Overall, it's reasonably complete for a code-generation 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 has 100% description coverage, with each parameter clearly described. The description itself adds no additional parameter meaning, so it scores the baseline of 3. It doesn't need to add more because the schema already handles parameter semantics well.
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 uses the verb 'Make' and clearly states the output: source code of a governor contract formatted in Markdown. It distinguishes the tool as a governance contract generator, but it doesn't explicitly mention Stellar or Soroban in the description itself, leaving some ambiguity when compared to sibling governor tools like solidity-governor and cairo-governor.
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 gives no guidance on when to use this tool over alternatives. It doesn't mention Stellar-specific context, prerequisites, or exclusions. An agent would have to infer usage solely from the tool's name, which is insufficient for selecting among multiple governor tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It clearly states the output format (Markdown code block) and the lack of disk side-effects, which is valuable. It does not mention potential errors, permissions, or deployment behavior, but for a code generation tool these are the key aspects.
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, front-loaded with the main purpose and immediate behavioral details. No wasted words or 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?
The description covers the essential aspects: purpose, output format, and side effects. The schema documents parameters thoroughly. The lack of explicit mention of the Stylus/Rust platform is a minor gap, but the tool name provides that context, so the description is substantially 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 100%, with each parameter (name, burnable, enumerable, info) already explained clearly. The tool description adds no extra meaning to 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action 'Make a non-fungible token per the ERC-721 standard' and identifies the resource (token). It does not explicitly mention 'Stylus' or 'Rust', so it doesn't differentiate between sibling erc721 tools for Solidity or Cairo, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternative ERC-721 generators. The note about returning source code and not writing to disk is behavioral, not usage guidance. There are no explicit when/when-not or alternative recommendations.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully states that the tool returns source code formatted as a Markdown code block and that it does not write to disk. This gives an agent a clear expectation of side effects and output format, though it does not mention broader behaviors such as whether any deployment or network interaction occurs.
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 concise sentences, front-loading the main purpose and immediately following with the key output format and side-effect note. There is no filler, repetition, or unnecessary detail.
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 code-generation tool, the description covers the target platform, return value, and non-persistence, while the schema covers all inputs. It does not explicitly state that the contract is not deployed or that no blockchain transaction occurs, but the 'Does not write to disk' line implies a local generation-only operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3; the description itself adds no parameter-level semantics. The schema already documents all five parameters and their nested fields with useful descriptions, so the lack of parameter details in the description is acceptable.
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 states a specific action ('Make a custom smart contract') and resource ('TRON Virtual Machine'), and the word 'custom' distinguishes it from standard TRON templates like tron-trc20 or tron-trc721. It is not a tautology and clearly indicates what the tool produces, though it could more explicitly describe the nature of the customization.
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 rather than the many sibling tools. The description relies on the word 'custom' to imply that it is for non-standard contracts, but it never names alternatives like tron-trc20, tron-trc721, or other chain-specific custom tools. An agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It explicitly states that the tool returns source code formatted as a Markdown code block and does not write to disk, which are key behavioral and side-effect guarantees for a code generation 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?
Two concise sentences: the first states the purpose and the second states the output format plus the key side-effect limitation. Every sentence 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?
For a 12-parameter generator with no output schema and no annotations, the description adequately covers what is returned and that nothing is written to disk, while the schema covers all parameter semantics. It is nearly complete, though explicitly naming Solidity in the description would improve standalone clarity.
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%, and the schema already provides detailed field-level explanations for all 12 parameters. The description adds no parameter-specific detail, so the baseline score for schema-covered parameters applies.
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 uses a specific verb ('Make') and a clear resource ('a non-fungible token per the ERC-1155 standard'), and clarifies that it returns generated source code. It distinguishes from unrelated generator tools, but it does not explicitly name Solidity or contrast with the Cairo/Stylus ERC-1155 siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance or mention of alternatives. The description only states what the tool generates; it does not help the agent decide between this and sibling tools such as solidity-erc721, stylus-erc1155, or cairo-erc1155 beyond relying on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses valuable behavioral traits: it returns the source code formatted in a Markdown code block and explicitly states it does not write to disk. With no annotations provided, this fills the safety/behavioral gap and clarifies the tool's non-persistent, generation-only nature. It does not elaborate on error handling or permissions, but that is acceptable for a code generation 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 three short sentences with the core purpose front-loaded. Each sentence contributes essential information: the function, the return format, and the non-write behavior. There is no redundant text 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 substantial schema coverage (83%) and the simple behavior of a code generator, the description is sufficient: it explains the core action, the output format, and that it does not write to disk. However, it lacks explicit guidance on tool selection among siblings, which would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%) and the schema contains detailed descriptions for each parameter (e.g., access types, dar delays, pausable, upgradeable). The tool description adds no parameter-level information, so the baseline of 3 applies as the schema already carries the semantic weight.
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 'Make a custom smart contract' and specifies the output as source code in a Markdown code block. The tool name 'cairo-custom' together with sibling context (e.g., solidity-custom, cairo-erc20) distinguishes it as a custom Cairo contract generator, avoiding confusion with standard token or other language templates.
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 usage guidance is provided. The description does not mention when to choose this tool over the standard templates (erc20, erc721, etc.) or other custom generators (solidity-custom), and there are no preconditions, exclusions, or alternatives described.
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 behavioral burden. It clearly discloses that the tool 'Returns the source code... in a Markdown code block' and 'Does not write to disk', which are key behavioral traits for a code generation tool. However, it does not mention potential errors, validation behavior, or whether any external calls are made, so it is not fully exhaustive.
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 only two sentences and front-loads the core purpose ('Make a custom smart contract'), followed by output format and side-effect disclosure. Every sentence provides essential value without redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a code generation tool with a rich schema (5 parameters, nested object), the description sufficiently covers the return value (source code) and side effects (no disk write). The main gap is usage guidance relative to sibling tools, but many behavioral aspects are already covered by the schema and the description, making it fairly complete overall.
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 description does not need to explain parameters in detail. The schema already provides rich descriptions for all five parameters including nested info fields. The description does not add any parameter-specific meaning but none is needed due to the 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 'Make a custom smart contract' with a specific verb and resource. It distinguishes from standard token generators (solidity-erc20, etc.) by emphasizing 'custom', and the language context is clear from the tool name 'solidity'. The output behavior (source code) is also specified, making the purpose unambiguous.
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 standard contract generators or the cairo-custom sibling. While 'custom' implies it's for non-template contracts, there is no direct statement of prerequisites, exclusions, or alternative tools, so the agent receives limited decision support.
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 to rely on, the description carries the full burden of behavioral disclosure. It explicitly states that the tool returns source code in a Markdown code block and does not write to disk, which transparently communicates the side-effect-free nature and output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: first sentence states the purpose, second sentence describes behavior and output. Every word earns its place, and the most important information is front-loaded.
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 the tool's complexity (11 params, nested objects), the description covers the core action and return format, which is essential given no output schema exists. The schema itself provides deep parameter detail, making the combination adequate for a knowledgeable 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% and each parameter has detailed descriptions, so the schema already handles parameter semantics. The tool description itself adds no parameter-specific meaning, matching the baseline for comprehensive 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 uses a specific verb and resource ('Make a Uniswap v4 hook contract') and is distinct from sibling tools which generate other contract types (ERC20, ERC721, etc.). It clearly identifies the tool's focus and scope.
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. The description states what the tool does but does not mention any exclusions, prerequisites, or context in which a different contract generator would be more appropriate.
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 behavioral burden. It explicitly discloses that the tool generates source code, returns it in a Markdown code block, and does not write to disk — key safety-relevant behavior. It does not disclose whether the generated contract is audited, whether it includes tests, or whether it may have chain-specific limitations, but the critical no-write behavior is clearly stated.
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?
Two sentences with no filler. The key output/behavior detail (returns Markdown, does not write to disk) is front-loaded in the second sentence. It is appropriately concise for a tool with a rich schema.
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 17 parameters and nested objects, the schema is thorough and self-contained: defaults, conditional fields, and enum constraints are documented. The description covers the essential behavioral contract (code generation, return format, no disk write). Missing context includes what the generated code actually contains or whether cross-chain execution requires extra deployment steps, but the schema covers the key decision points and the output is source code, not a complex API response.
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 does not add parameter-level semantics beyond the schema, but the schema itself thoroughly documents each parameter with defaults and conditional relationships (e.g., decimals default differs by voting type, quorumPercent applies only when quorumMode equals percent). The description's high-level purpose helps the agent infer how parameters combine, but it doesn't add any extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Make a contract to implement governance'), a specific resource ('for a DAO, targeting the TRON Virtual Machine'), and explicitly says it returns generated source code without writing to disk. This clearly distinguishes it from sibling tools like solidity-governor or cairo-governor by naming the TRON Virtual Machine target.
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 does not explicitly say when to use this tool versus alternatives. However, the tool name (tron-governor), the target 'TRON Virtual Machine', and sibling list of other chain-specific generators imply it is the choice for TRON governance contracts. No explicit exclusions or alternative routing are provided, leaving usage inference largely to the agent.
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 specifies that the tool returns source code in a Markdown block and does not write to disk, which are essential behaviors. However, it does not mention any potential side effects beyond that, but for a code generator these two are the most critical.
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 concise sentences with no filler. The purpose is front-loaded, and the behavioral note about output and disk usage adds value without 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?
For a tool with 11 parameters and nested objects, the description covers the core purpose, output format, and side-effect avoidance. It does not clarify the interaction between 'minimal' and the optional features, but the schema descriptions cover each parameter adequately. Overall, it is sufficiently complete for an agent to call 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?
The schema description coverage is 91%, so the parameters are well-documented in the schema itself. The description adds no extra meaning to parameters, only the general notion of 'minimal' which might be ambiguous. Baseline 3 is appropriate given the high 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 action ('Make a minimal multi-token') and the specific standard (ERC-6909), which distinguishes it from sibling tools like cairo-erc20 and cairo-erc721. It also clarifies that it returns source code, removing any ambiguity about being a generator.
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 ERC-6909 tokens via the standard name, but it does not explicitly mention when to choose this tool over alternatives or provide exclusions. Since siblings cover other standards, the guidance is only implicit.
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 correctly carries the burden of disclosing side effects. It explicitly states 'Returns the source code... formatted in a Markdown code block' and 'Does not write to disk', which are critical behavioral traits for a generator tool. This goes beyond a minimal description and gives the agent confidence about output and side-effect safety.
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 exactly two sentences. The first sentence is a front-loaded statement of the tool's purpose, and the second adds essential output and side-effect info. Every word earns its place—no fluff, no repetition of schema details. This is a model of concise, well-structured documentation.
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 a rich schema (5 parameters, nested objects) and no output schema. The description compensates by explicitly describing the return format (Markdown code block) and the key non-side-effect ('Does not write to disk'). It does not cover usage time or alternatives, but for a straightforward generator, the description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all five parameters already have detailed descriptions in the schema. The tool description adds no additional parameter semantics, which is acceptable given the schema's completeness. The baseline of 3 applies because the schema does the heavy lifting and the description does not need to compensate.
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 starts with a clear, specific action: 'Make a multi-signature smart contract'. It immediately identifies the resource (multi-sig contract) and the core requirement (quorum of registered signers). This distinguishes it from sibling tools like cairo-governor or cairo-erc20, which serve different contract types.
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 by defining what the tool does, but it does not explicitly state when to use it over alternatives (e.g., 'use this for multisig, use cairo-governor for governance'). There is no mention of exclusions or alternative tools, leaving the agent to infer applicability from the tool name and description.
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 clearly states the output behavior ('Returns the source code... formatted in a Markdown code block') and side-effect freedom ('Does not write to disk'). This adds valuable context beyond the schema, though it doesn't cover potential errors or auth requirements.
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 highly concise, containing only two sentences that front-load the core purpose and immediately follow with output/behavior details. Every sentence earns its place with no extraneous content.
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 having 9 parameters, the schema compensates with rich descriptions. The description sufficiently covers the tool's function (generation, not deployment) and output format, and explicitly notes it does not write to disk. This provides enough context for selection and invocation, though it omits advanced details like dependencies or verification steps.
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 does not add additional meaning to parameters beyond what the schema already provides; it only mentions the token is confidential and similar to ERC-20, which is general context rather than parameter-specific clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Make a confidential fungible token in Solidity according to the ERC-7984 standard,' which clearly identifies the action (make/generate) and resource (confidential token contract). It also distinguishes from sibling tools like solidity-erc20 by highlighting the confidentiality aspect, making the purpose 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 confidential tokens ('similar to ERC-20 but with confidentiality'), but it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or contrast with any specific sibling tool. Usage guidance is only implicit, not directly stated.
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 full burden of side-effect disclosure. It clearly states that the tool returns source code formatted in a Markdown code block and does not write to disk, which are essential behaviors. It does not mention other potential behaviors like error handling or network access, but the main side-effects are covered.
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, with the core purpose stated first and additional behavior (output format and no disk write) in the second. Every sentence earns its place, and there is 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 has 17 parameters and no output schema, but the description provides key context: it returns source code and has no filesystem side effect. Since the schema covers all parameters in detail, the description is sufficient for an agent to understand the tool's purpose and output. It lacks a high-level overview of configuration choices, but this is not critical given the schema richness.
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 100% coverage of all 17 parameters with detailed descriptions, so the tool description does not need to add parameter semantics. The description mentions no specific parameters, which is acceptable given the schema's thoroughness. Baseline of 3 applies because the description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Make a contract to implement governance') and clearly identifies the resource (a governance contract, such as for a DAO). It distinguishes itself from sibling tools by noting it returns source code in a Markdown code block and does not write to disk, which is unique among the listed code generators.
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 generating Solidity governance contracts, but it does not explicitly state when to prefer this over alternatives like cairo-governor or stellar-governor. There is no mention of alternatives, prerequisites, or exclusions, so guidance is only implicit from the tool's name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing the output format (Markdown code block) and that it does not write to disk. This is a key behavioral trait that prevents assumptions about file-side effects. The description could mention additional behavior like input validation, but it is not essential for this type of 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 two concise sentences, front-loading the purpose and then providing output and side-effect details. Every clause adds value, with no repetition of schema content or filler. This is a model of efficient description writing.
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 12 parameters, no output schema, and no annotations, the description adequately covers the essential behavior: what it generates and what it returns. The schema fully documents parameters, so the description does not need to explain them. The only minor gap is that the return format is described but not explicitly tied to a success/failure scenario, but this is sufficient for an agent to invoke and interpret results.
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 12 parameters have schema descriptions (100% coverage), so the schema documents the parameters thoroughly. The description adds only the high-level ERC-20 analogy, which reinforces the meaning of standard token options but does not add per-parameter detail. 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?
The description clearly states the tool generates a fungible token contract per SEP-41, distinguishing it from sibling non-fungible, stablecoin, and EVM/Cairo variants. The phrase 'Returns the source code of the generated contract' clarifies that it is a code generator, not a deployer, making the purpose 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?
Usage context is implied through the tool name 'stellar-fungible' and the SEP-41 compatibility reference, but the description does not explicitly state when to choose this over alternatives like solidity-erc20 or cairo-erc20. The 'similar to ERC-20' analogy helps with familiarity but not with selection criteria.
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 discloses important behavioral details: it returns the generated source code as a Markdown code block and does not write to disk. This clarifies expected output and side effects. It could add more about potential validation or timing, but the key non-obvious 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence states the core function, and the second explains the output and side-effect. It front-loads the purpose and is appropriately sized for the tool's simplicity.
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 13 parameters and no output schema, but the description provides the essential context: what is generated, the standard it follows, the output format, and the 'no disk write' guarantee. The schema covers parameter details. This is sufficiently complete for a code-generation tool, though it could benefit from a brief example or note on SEP-41 compatibility.
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 for all 13 parameters with detailed descriptions. The description itself does not add parameter-specific semantics or go 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 clearly states the tool creates a stablecoin using the Fungible Token Standard compatible with SEP-41. The verb 'Make' is action-oriented, the resource is a stablecoin contract, and it distinguishes itself from sibling tools like solidity-stablecoin or cairo-erc20 by specifying the Stellar/SEP-41 context.
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 implicitly indicates when to use this tool (when a Stellar SEP-41 stablecoin is needed) but provides no explicit comparisons to alternatives. It doesn't say 'use this instead of X' or list exclusion criteria, so while context is clear, usage guidance is not fully explicit.
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 correctly discloses key behavioral traits: it 'Returns the source code... in a Markdown code block' and 'Does not write to disk.' This goes beyond the bare minimum by clarifying side effects and return format, which is especially useful for a code generator.
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: the first states the purpose, the second states return behavior and side-effect. No filler, front-loaded, every sentence 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?
For a simple generator with no output schema, the description explains the return format (Markdown code block) and explicitly notes no disk write, which covers important behavioral context. It does not explain how to use the returned code or list parameter options, but those are documented in the schema, so the description is largely 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 100%, with each parameter having a clear description (e.g., 'burnable' means 'Whether token holders will be able to destroy their tokens'). The tool description adds no extra parameter-specific meaning beyond noting the ERC-1155 standard, so 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?
The description uses a specific verb+resource: 'Make a non-fungible token per the ERC-1155 standard.' This clearly distinguishes it from siblings like stylus-erc20 (fungible) and stylus-erc721 (different NFT standard), and states that it returns source code, making the purpose unmistakable.
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 when to use the tool (for ERC-1155 token generation) but provides no explicit comparison or exclusion relative to alternatives like stylus-erc20 or solidity-erc1155. It lacks any 'when not to use' or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral disclosure burden. It explicitly states the output is source code formatted as a Markdown code block and that it does not write to disk, which is valuable side-effect information beyond what the schema could convey.
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: the first states the core purpose and the second covers the output format and key side-effect. Every sentence earns its place and there is no filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a code-generation tool with a well-described 16-parameter schema but no output schema, the description adequately covers the return value and side effects. It explains what the agent will receive, how it is formatted, and that nothing is persisted, which is sufficient for agent judgment.
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 100% of the 16 parameters, so the tool description does not need to repeat them. The description adds no specific parameter-level guidance, but the schema itself is sufficient, 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 clearly states the tool generates a non-fungible token according to the ERC-721 standard, and it clarifies that the result is source code rather than a deployed asset. This is specific enough to distinguish it from the many ERC-20, ERC-1155, Cairo, and Stylus siblings.
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 should be used when ERC-721 contract source is needed, but it does not explicitly say when to use it versus alternatives like solidity-erc1155, cairo-erc721, or solidity-custom. There is no when-not-to-use guidance or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that the tool returns code in a Markdown block and does not write to disk, which clarifies the side-effect-free nature. It lacks details about failure modes or prerequisites, but for a code generator this is reasonably transparent.
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, front-loaded with the primary purpose and followed by a critical behavioral note about return format and non-persistence. Every sentence earns its place with zero 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?
The tool has 7 parameters and no output schema, so the description must cover return values, which it does. It explains the generated contract's purpose and the output format. It could add more about parameter interdependencies, but those are already handled in the schema, making the context sufficiently 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 100%, so the baseline is 3. The tool description does not add any parameter-level meaning beyond the schema; all parameter explanations are in the schema itself, so it neither enhances nor detracts.
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: generating a vesting smart contract that manages gradual ERC-20 token release. It specifies the resource (vesting contract) and behavior (returns source code), distinguishing it from sibling contract generators like cairo-erc20 or cairo-custom.
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 provides clear context for when to use the tool—whenever a vesting contract is needed. It implicitly distinguishes from alternatives by focusing on vesting, but does not explicitly name alternatives or state exclusion conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explicitly states return format ('source code of the generated contract, formatted in a Markdown code block') and a critical side-effect ('Does not write to disk'). This is valuable behavioral transparency beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately front-loaded with the primary purpose, followed by key output and side-effect information. Every sentence 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, nested objects, no output schema), the description covers the essential context: what it generates, the return format, and that it does not persist to disk. It does not explain all parameter behaviors, but the schema handles that comprehensively. The description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself does not add any parameter-level details, but the schema already provides exhaustive descriptions for all 9 parameters, including enums and options. The description's mention of the ERC-4337 standard gives some context for the parameters.
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: 'Make an account contract that follows the ERC-4337 standard.' It uses a specific verb ('Make'), a specific resource ('account contract'), and a standard ('ERC-4337') that distinguishes it from sibling code generators like cairo-account and solidity-erc20.
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 provides clear context: it is for Solidity account contracts following ERC-4337, which implicitly distinguishes it from Cairo or other contract types. However, it does not explicitly state when not to use it or name alternatives, though the sibling list makes the context 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 burden of disclosing side effects. It explicitly states that the tool 'Returns the source code of the generated contract, formatted in a Markdown code block' and 'Does not write to disk', which are critical behavioral traits. It does not mention permissions, network access, or potential errors, but for a code generator, these are less relevant. The description adequately signals that no persistent changes are made.
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, consisting of only two short paragraphs. It front-loads the primary purpose, then immediately discloses the output format and lack of disk write. Every sentence contributes essential information without redundant phrases. This is an ideal example of efficient writing.
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 tool's complexity (8 parameters, nested objects, no output schema), the description covers the core purpose and output format. Since the schema already documents all parameters in detail (100% coverage), the description does not need to repeat those. It provides a use-case example and side-effect transparency, which are the missing pieces. It could be more complete by mentioning that policy contracts are required for threshold policies, but that is already in the schema. Overall, it is adequate for an agent to invoke 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 description coverage is 100%, so the baseline is 3. The description adds a meaningful example ('multisig with passkey, Ed25519 and delegated signers') that illustrates how parameters like webauthnSigners, ed25519Signers, and delegatedSigners interact, but it does not provide additional semantics beyond what the schema already documents. This is sufficient, but not above the baseline.
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 generate a smart account contract on Stellar with configurable signers and policies. It provides a concrete example (multisig with passkey, Ed25519, and delegated signers) and distinguishes it from sibling tools like stellar-fungible or stellar-governor by its focus on account contracts. The verb 'Make' combined with the resource 'smart account contract' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need a Stellar smart account with specific authorization logic. It gives an example of multisig use cases, which suggests typical scenarios. However, it does not explicitly mention when NOT to use it or compare it to alternatives (e.g., 'for a simpler account, use X'). Still, the context from sibling names and the description's clarity provide sufficient guidance for most cases.
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. It explicitly states the tool returns source code in a Markdown code block and does not write to disk, disclosing the key side-effect-free behavior. No other behavioral traits are needed for this code-generation 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 concise with two sentences, front-loading the core purpose and adding essential behavioral details. 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 rich schema and no output schema, the description appropriately covers the return format and side-effect-free behavior. It is sufficient for an agent to select and invoke the tool correctly, though it could optionally mention how the generated code integrates with Stellar.
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% parameter description coverage, so the baseline is 3. The tool description does not add any additional parameter semantics 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 generates a non-fungible token contract for Stellar, explicitly referencing SEP-50 and ERC-721. It distinguishes from sibling tools like stellar-fungible and other chain-specific ERC-721 generators.
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 provides clear context for when to use the tool (Stellar NFT generation, SEP-50 compatible), but does not explicitly mention exclusions or alternative tools. The mention of 'similar to ERC-721' implies a comparison, but no direct 'use X instead' guidance.
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 explicitly states that the tool 'does not write to disk' and returns code in a Markdown block, which are key behavioral traits for a code generator. It does not describe other potential side effects, but for a generation-only tool this is sufficient.
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 primary purpose and followed by the return behavior. Every sentence contributes unique information without redundancy, making it highly efficient.
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 tool's complexity (8 parameters, nested objects) and the absence of an output schema, the description does enough by stating the output format and side-effect-free nature. The schema covers parameter details, so the description's brevity does not leave a critical gap. Slightly more context about contract generation behavior could push it higher.
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 100% coverage with detailed descriptions for all 8 parameters, including nuances like decimalsOffset and explicitImplementations. The tool description itself adds no parameter-level detail, so the baseline of 3 applies due to 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 tool's function with a specific verb ('Make') and resource ('tokenized vault'), and distinguishes it from sibling Stellar tools by emphasizing its vault nature and ERC-4626 similarity. The second sentence clarifies that it returns generated source code, making the purpose unambiguous.
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 provides clear context for when to use this tool: when a tokenized vault issuing Fungible Token shares for an underlying asset is needed. It does not explicitly mention alternatives or exclusions, but the 'similar to ERC-4626' anchor and the distinct vault concept make the use case evident relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states that the tool returns source code in a Markdown code block and does not write to disk, which are the key behavioral traits an agent needs to know. It does not mention every possible side effect, but for a code-generation tool, these disclosures are substantial and useful.
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 and every sentence earns its place. The first sentence identifies what the tool generates and the target platform; the second conveys the return format and the non-destructive behavior. It is front-loaded and free of 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 12 parameters with full schema coverage and no output schema, the description appropriately clarifies the return format (Markdown code block) and the side-effect profile (does not write to disk). It does not enumerate generated contract features, but the standard name and schema descriptions cover the necessary details for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters. The description adds no additional parameter-level semantics, but it is not required to compensate because each parameter already has a thorough description in the schema. This meets the baseline for a fully documented 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 states a specific verb ('Make'), a clear resource ('multi-token contract per the TRC-1155 standard'), and a specific target ('TRON Virtual Machine'). This clearly distinguishes it from sibling tools like tron-trc20, tron-trc721, and solidity-erc1155. The additional note about returning source code and not writing to disk further clarifies what the tool actually does.
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 the intended use clear: use this tool when you need a TRC-1155 multi-token contract targeting TRON. It does not explicitly list alternatives or when-not-to-use conditions, but the standard and target are stated precisely enough that an agent can select it over related siblings like tron-trc20 or tron-trc721.
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?
No annotations are provided, so the description carries the full burden. It makes the side-effect-free behavior explicit ('Does not write to disk') and describes the return format ('formatted in a Markdown code block'), which are the key behavioral traits an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the core action is first, and the critical non-side-effect and output-format traits follow. Every sentence 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?
The tool has 18 parameters and no output schema, but the description covers the essential invocation context: the standard, target VM, return shape, and absence of disk writes. It does not detail deployment behavior, but that is not implied by the tool's role as a code generator.
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%, and every parameter has a descriptive schema entry, so the description need not repeat parameter meaning. It adds no parameter guidance beyond the schema, which matches the baseline for full 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?
Description uses a specific verb-resource pair: 'Make a fungible token per the TRC-20 standard, targeting the TRON Virtual Machine.' This clearly separates it from solidity-erc20, cairo-erc20, and TRON non-fungible siblings.
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 TRON Virtual Machine context makes it clear this is the tool for TRC-20 fungible tokens, and the output description indicates it is a code generator rather than a deployment tool. It doesn't explicitly compare against tron-custom or tron-trc721/1155, but the standard and target are unambiguous.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly says the tool returns generated source code in a Markdown code block and does not write to disk, making the pure code-generation behavior explicit. It could also mention no deployment occurs, but the no-write statement substantially covers side-effect 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?
Two short paragraphs with no filler: purpose first, then output format and side-effect caveat. Every sentence earns its place, and the key facts 'Returns source code' and 'Does not write to disk' are immediately available.
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 code-generation tool with a rich 16-parameter schema, the description covers purpose, output format, and side-effect boundary in two sentences. There is no output schema, but the description compensates by specifying the return format. It does not detail all possible behaviors, but the key invocation-relevant information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have documented meanings in the schema. The description does not add parameter-level detail, but it clarifies that the output is a generated source code artifact rather than an actual chain deployment. 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?
States explicitly that the tool makes a non-fungible token per the TRC-721 standard on the TRON Virtual Machine. The verb 'Make' plus the resource 'non-fungible token per TRC-721' clearly distinguishes it from siblings such as tron-trc20 and tron-trc1155.
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 defines the use case by standard and target platform: it is the tool for TRC-721 non-fungible token contract generation on TRON. It does not explicitly name alternatives or state when not to use it, but the context is clear enough to route correctly among the TRON siblings.
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:

[![contracts-wizard MCP server](https://glama.ai/mcp/servers/OpenZeppelin/contracts-wizard/badges/card.svg)](https://glama.ai/mcp/servers/OpenZeppelin/contracts-wizard)

Score Badge

Copy to your README.md:

[![contracts-wizard MCP server](https://glama.ai/mcp/servers/OpenZeppelin/contracts-wizard/badges/score.svg)](https://glama.ai/mcp/servers/OpenZeppelin/contracts-wizard)

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/OpenZeppelin/contracts-wizard'

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