Se ja possuis o NFT: liga o teu nome a ele para sempre. Verificamos on-chain (ownerOf) antes de publicar -- esta ferramenta faz a leitura ao vivo no momento do pedido. Requer token_id, wallet, nome. (gratis (requer posse do NFT))
| Name | Required | Description | Default |
|---|---|---|---|
| nome | No | Como queres ser lembrado. | |
| wallet | No | A tua carteira Ethereum que possui o NFT agora. | |
| mensagem | No | Opcional. | |
| token_id | No | Numero do token NFT que compraste (ver nft_catalogo). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an on-chain read (ownerOf) at request time and notes permanence ('para sempre') and cost ('gratis'). However, it is vague about what 'publicar' entails — whether it is a blockchain write or a simple record — and does not explain failure modes or reversibility. This is moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the main purpose. It uses a run-on structure with em-dashes and parentheses, but every sentence contributes meaningful information. It could be cleaner, but it is not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description covers prerequisites and the verification step, but does not describe what happens after success or on failure, and does not clarify the exact nature of the final 'publish' action. It is adequate but leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a requirement statement ('Requer token_id, wallet, nome') and clarifies that the wallet must currently own the NFT, which matches the schema. However, it contradicts the schema's required parameters list (schema says 0 required, description says 3 required), so it adds some value but also creates confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: link your name to an NFT permanently. It also mentions on-chain ownership verification, which distinguishes it from the symbolic sibling tool nft_dedicar_simbolica. However, it does not explicitly name the sibling or contrast with it, so it loses a point for not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear precondition: 'Se ja possuis o NFT' (if you already own the NFT) and lists the required parameters (token_id, wallet, nome). This tells when to use the tool. However, it does not mention alternatives or explicitly say when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but nft_dedicar and nft_dedicar_simbolica are easily confused as both link a name to an NFT, differing mainly in ownership requirement and payment. Also, licenca_formal and receber_obra may be confused as both involve acquiring an artwork, though one is a paid license and the other a free gift; descriptions help clarify.
The tool names mix verb-first (doar, receber_obra) and noun-first patterns (nft_catalogo, parceiro_estado), and while they all use snake_case, there is no consistent verb_noun structure across the set. Some names use adjectives (nft_owner_atual, nft_dedicar_simbolica) making the pattern unpredictable.
With nine tools covering the collection, licensing, dedication, donation, and partner program, the server is well-scoped within the typical 3-15 range. Each tool serves a distinct function in the ecosystem.
The server covers the main interactions with the 0001sensations collection, including receiving, licensing, cataloguing, dedicating, and checking ownership. Minor gaps exist, such as no direct tool to browse the physical FISICA collection or manage licenses, but these are workaroundable via URLs or not essential.