mycel-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the upstream source is Frankfurter with ECB reference rates updated daily, and the service is free with no API key required, which tells the agent there is no auth step or credential prerequisite. It does not describe failure behavior for invalid currency codes.

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 core facts (what it does, source, freshness, no key needed, empty-target behavior) are front-loaded and easy to scan. The cost is that every sentence is duplicated verbatim in Chinese, doubling length, though that duplication is clearly deliberate localization rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-optional-parameter read-only lookup with full schema coverage and read-only annotations, the description supplies the missing operational context: source, update cadence, and no-auth access. With no output schema present, it could have stated what the response contains (rate value vs. converted amount), which is the one remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: base and target accept either ISO currency codes or Chinese currency names, and an empty target returns a basket of common currencies. That name-vs-code flexibility is non-obvious and materially improves correct invocation. It does not clarify the conversion output shape when amount is omitted.

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 names a concrete resource and action: live currency exchange rates plus amount conversion, and identifies the data source (Frankfurter / ECB reference rates). An agent can tell immediately this is a read-only FX lookup tool, clearly distinct from the weather, IP, and mycel siblings. It stops short of a crisp single-verb framing because the opening is a noun phrase rather than an imperative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through the 'leave target empty for a basket of common currencies' instruction, which is really parameter behavior rather than tool selection guidance. There are no sibling tools that overlap in function, so alternatives are not needed, but there is also no statement of when-not-to-use (e.g., historical rates, crypto, or non-ECB currencies are out of scope).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and openWorldHint annotations, the description adds useful behavior: data is real-time, cached for 5 minutes, free, and requires no API key. It does not mention rate limits or response-shape details, but the annotations already cover the safety profile.

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 front-loaded and contains no filler, but the English and Chinese versions repeat the same information, roughly doubling length. The repetition is intentional for bilingual clarity but is still redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with two optional parameters, no output schema, and complete schema descriptions, the definition covers data source, freshness, cost, authentication, and caching. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents both parameters at 100% coverage, including platform values, 'all', limit range, and default. The description reinforces platform coverage but adds no syntax or semantics beyond the schema, so the baseline 3 is appropriate.

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 specific verb/resource: live trending/hot lists from named Chinese platforms, with the full platform scope including 'all'. It is immediately clear what the tool returns and for which sources.

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?

It gives clear usage context: real-time hot lists, cached for 5 minutes, free, and no API key required. It does not explicitly say when not to use it, but the sibling tools are unrelated, so the intended use is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the description's job is to add context, which it does: live lookup against ip-api.com, free, no API key required. It does not mention rate limits (ip-api.com's free tier is throttled), accuracy caveats, or how invalid/non-IPv4 input is handled, which is the main remaining behavioral gap.

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 English sentence is front-loaded and wastes nothing, but the entire block is duplicated verbatim in Chinese, roughly doubling length without adding information for an English-reading agent. The structure is clean; the redundancy is the issue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly takes on the burden of naming the returned fields, and it discloses the upstream provider and the no-key constraint. What's missing is rate-limit/error behavior and any note that IPv6 is unsupported beyond the implicit 'IPv4' wording.

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% and the single 'ip' property already documents both the format and the 'empty = caller IP' default. The description adds no syntax, validation, or formatting detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Look up the geolocation and network operator of an IPv4 address') and enumerates exactly what comes back: country, region, city, coordinates, timezone, ISP, ASN. The IPv4-only scope also implicitly separates it from any generic network tool, and none of the siblings (weather_query, exchange_rate, mycel_*) overlap.

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?

Usage context is clear: look up an arbitrary IPv4 address, or omit it to resolve the caller's own IP. There is no explicit 'when not to use' or exclusion, but with no competing sibling tool the only realistic alternative is not calling it, so the gap is small.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds genuinely new behavioral information beyond that: the call does not consume credits, which matters for an agent deciding whether it can poll the balance. It does not describe the returned balance format, but with no output schema that gap is minor for a zero-parameter read.

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 first sentence front-loads the purpose and the second adds the key non-obvious fact about cost. The English and Chinese sentences are direct translations of each other, so roughly half the text is redundant for any single reader, but no sentence is otherwise wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, zero-argument, read-only balance check, the description covers what is read, whose balance it is, and that it is free of charge. The only omission is what the response looks like (units, breakdown), which is a small gap given there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. Nothing in the description conflicts with the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Check the credit balance') and scopes it to 'the account that owns the API key', so the agent knows exactly what is being read. It does not explicitly differentiate itself from the siblings (mycel_discover, mycel_hire_agent, mycel_models, mycel_task_status), though their purposes are plainly distinct.

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?

'Does not consume credits' implies this is safe to call freely before or around paid operations, which is a useful usage cue. However, there is no explicit statement of when to call it versus the sibling tools or any preconditions, so guidance remains implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network scope are covered structurally. The description adds genuinely new context: the call is free and needs no API key, which affects whether an agent should gate it behind user confirmation. Return shape is also disclosed, though pagination or catalog size is not.

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 English text is front-loaded with purpose, then return values, then cost, then the workflow cue — a good ordering with no wasted clauses. The full bilingual duplication doubles the length, which is defensible for a dual-audience tool but is still redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no input parameters and no output schema, the description carries everything an agent needs: what it returns, that it is free and keyless, and when to call it relative to hiring. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly implies the call takes no arguments by presenting it as an unfiltered catalog listing.

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 gives a specific verb and resource — 'List the AI agent nodes currently available for hire on the Mycel network' — and names the returned fields (agentId, name, capability description). It is immediately distinguishable from mycel_hire_agent, which is the action it feeds into.

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?

'call this before hiring to see who is available' establishes the workflow ordering and implicitly points at mycel_hire_agent as the follow-up. It does not spell out exclusions (e.g. when to use mycel_models instead), so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: the call consumes credits, may return either a result or a task_id (async behavior), and needs an API key. What it does not disclose is the failure/retry economics — annotations say idempotentHint=false, yet the description never warns that a retry could double-charge, nor how many credits a hire costs.

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 English text is front-loaded and efficient: purpose, prerequisite, return shape, and auth all land in four tight sentences. The full bilingual duplication roughly doubles the length, which is defensible for a multilingual platform but does inflate the payload without adding new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description carries the return contract itself and does so adequately — either the task output or a task_id to poll. Combined with cost, auth, and workflow-order details, an agent has everything needed to invoke this correctly and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines both parameters and the baseline is 3. The description adds only marginal meaning: that agent_id must be sourced from mycel_discover and that prompt should be a natural-language task description, which is close to what the schema fields already say.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Hire a Mycel agent to execute a task") plus the outcome ("get the result back"), and explicitly names the two siblings that bracket it in the workflow: mycel_discover for the agent_id and mycel_task_status for polling. An agent can distinguish this from mycel_discover/mycel_task_status without opening any schema.

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?

Gives an explicit prerequisite ordering ("Get agent_id from mycel_discover first, then pass a natural-language prompt") and names the follow-up tool for the async case ("poll with mycel_task_status"). It also covers the access precondition ("Requires an API key") and the self-registration fallback with a concrete endpoint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only semantics, so the description earns credit for adding non-schemaized behavior: the call consumes no credits and needs no authentication key. That is real, actionable context for an agent deciding whether the call is safe and cheap, though nothing is said about rate limits or result size.

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?

Front-loaded with the core purpose and pricing behavior in one sentence, with the operational guarantees in the next. The description is then repeated verbatim in Chinese, which is redundant for a single-language agent but does not obscure the English content.

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?

There is no output schema, so the description must carry the return shape, and it does name the two returned items (models and credit price per call). For a parameterless read-only catalog query this is sufficient, though it does not say whether the list is paginated or how model identifiers are formatted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case. No parameter explanation is needed, and the description does not waste space pretending otherwise.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the LLM models') plus what is returned ('credit price per call'), which lets an agent identify the tool without opening the schema. It does not explicitly distinguish itself from the sibling mycel_discover, which could plausibly also enumerate platform offerings, so it stops short of a 5.

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 'Free, no API key required' line implies this is the cheap pre-flight lookup before paid calls, but the description never states when to use it versus mycel_discover or mycel_balance, nor any exclusions. Usage is inferable rather than directed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two useful pieces of context beyond that: the API-key prerequisite and the returned field set (review status, health status, call count, credits earned). It omits pagination and result-size behavior, which keeps it from a 5.

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 English sentence is tight and front-loaded, with the returned fields enumerated efficiently. The Chinese sentence, however, is a full restatement of the same content rather than an addition, effectively doubling the description length without adding information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, zero-parameter, read-only listing tool with annotations covering safety, this is close to complete: it states the auth requirement and previews the response fields, compensating for the absent output schema. Only pagination or result-size expectations are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a no-parameter tool is 4, and nothing in the text creates confusion about invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the cards') plus a clear scope ('published under the current API key'), which distinguishes it from discovery-oriented siblings like mycel_discover. It does not explicitly name the sibling it is not, so it falls short of a 5.

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?

Usage is implied by the scope phrase 'under the current API key' — an agent can infer this is for inspecting its own listings rather than browsing the marketplace. However, no explicit when-to-use or when-not guidance is given, and alternatives such as mycel_discover or mycel_update_card are never referenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds meaningful behavior beyond the annotations: the card is not live immediately because it goes through admin review, is capped at 5 cards per key, requires an ag_ API key (self-registered acceptable), and monetizes via price_points credits paid by hirers. Annotations only mark it as non-read-only, open-world, and non-idempotent; the description supplies the operational consequences.

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 English text is front-loaded with the core action and constraint, but the full bilingual duplication roughly doubles the length; the Chinese half adds no information for a non-Chinese reader. Content itself earns its place, mostly a structural redundancy issue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an open-world mutation tool with six parameters and no output schema, it covers the key unknowns: auth, quota, review latency, and payment direction. It stops short of saying what the tool returns (e.g., pending card ID or status), which would help an agent chain into mycel_my_cards or mycel_task_status.

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 reinforces that endpoint_url must be an https A2A endpoint returning message/send and that price_points is what other agents pay you, but this largely restates what the schema already documents rather than adding new format or constraint details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: register your own AgentCard with an https A2A endpoint so other agents can hire it. The 'be hireable' framing and the contrast with mycel_discover (where it appears) and mycel_hire_agent (the opposite direction) make it easy to distinguish from siblings.

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?

Clearly tells the agent the condition for use (you want your own agent listed and paid per call) and gives operational context: API key required, max 5 cards per key, admin review before listing. It does not explicitly route to mycel_update_card for editing an existing card or mycel_my_cards for checking state, so it falls short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses that registration is free, self-service, requires no key, and immediately returns usable credentials and trial credits. It does not explain repeated-call behavior, credential persistence, or whether the key is shown only once, but those are minor gaps for this simple tool.

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 front-loaded with the action and then efficiently covers outputs, prerequisites, and the exact invocation trigger. The Chinese text is a compact bilingual restatement rather than unrelated filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter registration tool, it supplies the purpose, authentication and cost prerequisites, expected result, usage trigger, and next step. This also compensates well for the absence of an output schema by explicitly naming the returned API key and trial credits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole optional name parameter already has a clear schema description and example, so schema coverage is 100%. The description's reference to creating an identity adds little parameter-specific detail, such as naming defaults or uniqueness requirements, making the baseline score appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool mints a Mycel identity and returns an ag_ API key plus trial credits. Its registration role and relationship to mycel_hire_agent distinguish it well from the sibling tools.

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?

It gives an explicit trigger: call this when mycel_hire_agent reports that an API key is missing. It also explains that no existing key or human approval is required and that the resulting credits can immediately be used with mycel_hire_agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds a genuinely useful cost note ('does not charge extra credits'), which is not derivable from annotations, but says nothing about whether the task result is retained, how terminal states are signaled, or polling behavior.

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?

Front-loaded with the core action and scoped in one short second sentence; the bilingual duplication doubles the length but serves an internationalized audience rather than adding noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool this is close to sufficient, and the mention of 'output' partially substitutes for the missing output schema. However, without an output schema the description should indicate what status values or output shape to expect, which it does not.

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?

With one parameter at 100% schema description coverage, the schema fully documents task_id. The description only restates 'by task_id' and adds no format, source, or validity guidance beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: check the status and output of a hire task, keyed by task_id. The 'hire task' framing implicitly links it to the sibling mycel_hire_agent (which creates the task) without explicitly naming that relationship.

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?

Usage is only implied — an agent can infer this is the polling companion to mycel_hire_agent — but the description never says when to call it versus alternatives, how often to poll, or whether it is safe to call repeatedly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes beyond the annotations by disclosing a real side effect: any change returns the card to pending review, which the agent cannot infer from readOnlyHint/idempotentHint/destructiveHint. It also flags the API-key requirement. It could still say whether omitted fields are left untouched and what happens when editing a card you do not own.

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?

Front-loaded with the mutable fields, then the side effect and auth requirement in short declarative sentences. The full bilingual duplication of every sentence is wasted tokens for an agent that reads one language, but the structure itself is tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter mutation with one required field and no output schema, the description covers scope, the review-state consequence, and auth. A note on partial-update behavior and failure cases for non-owned cards would close the remaining gap.

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 every parameter is already documented with its own description and the card_id links back to mycel_my_cards. The description lists the same field names but adds no format or partial-update semantics beyond what the schema supplies, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Update), the exact mutable fields (description / endpoint_url / price_points / capabilities), and the ownership constraint ("a card you own"). This clearly separates it from mycel_my_cards (likely read) and mycel_publish_agent (create).

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?

Implies the usage context via "a card you own" and the API-key requirement, so the agent knows this is owner-scoped editing. However, it never names an alternative or says when-not to use it (e.g., to change card_id or ownership, or to create a card use mycel_publish_agent).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond readOnlyHint/openWorldHint, the description discloses the data source (Open-Meteo), that results are live rather than from training data, and that no API key is needed. These are genuinely useful behavioral facts an agent could not infer from annotations. It omits error handling for unknown cities and any rate-limit behavior, keeping it short of a 5.

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 English portion is front-loaded and efficient, but the entire text is duplicated in Chinese, roughly doubling length without adding information. The bilingual format may serve locale needs, but purely as agent-facing content half the description is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only tool with no output schema, the description usefully lists the fields returned and the forecast horizon, which compensates for the missing output schema. The only notable gap is what happens with an unrecognized city name.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both city and days are already documented in the schema, and the description's mention of '1-7 day' merely restates the days constraint. It adds no syntax guidance such as how to disambiguate cities with the same name.

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 names a specific resource (real-time weather and 1-7 day forecast) and scope (any city worldwide), and enumerates the returned metrics (temperature, feels-like, humidity, wind, precipitation probability). No sibling tool covers weather, so there is no ambiguity with exchange_rate, ip_lookup, or the mycel_* tools.

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?

Usage is only implied by the word 'weather'; there is no explicit when-to-use or when-not-to-use statement and no named alternative. Given the sibling set, no real alternative exists, which limits the harm, but the guidance is still inferential rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.