game_implant_charge
Больница: зарядить вживлённый имплант (медь по цене импланта, 30 дней).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes |
Больница: зарядить вживлённый имплант (медь по цене импланта, 30 дней).
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, so the description carries most of the load. It discloses meaningful behavior: the action costs copper equal to the implant's price and the result lasts 30 days, and it must occur at a hospital. It does not mention permissions, failure modes, or what happens if the implant is not installed, but for a one-parameter tool this is solid added context.
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?
A single compact sentence with the location front-loaded and cost/duration parenthesized at the end; nothing is wasted. It is arguably over-terse given the undocumented item_id, but structurally it is clean and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and minimal annotations, the description covers location, cost, and duration well but leaves the meaning of the required argument unresolved. An agent knows what the tool accomplishes and its price, but not exactly which identifier to pass.
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 0% for the single parameter item_id, so the description must compensate and does not. It never clarifies whether item_id is the ID of the implanted implant, the implant item in inventory, or something else, nor its format beyond the 256-character cap in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('зарядить' = charge) and a specific resource ('вживлённый имплант' = implanted implant), prefixed with the location 'Больница' (Hospital). This lets an agent distinguish it from siblings like game_implant (installing an implant) or game_hospital_cure, though it does not name those siblings explicitly.
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 'Больница:' prefix implies the player must be at the hospital and have an implant already installed, and '(медь по цене импланта, 30 дней)' adds the cost and duration of the effect. There is no explicit statement of prerequisites, failure conditions, or an alternative tool to use instead, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.