Calligraphy Maker by Studio99

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

Annotations already disclose readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the project is written into the signed-in user's own account, the tool returns an openable link, and the SVG input must be full-quality Studio99 output. It omits auth/permission specifics and error behavior for rejected URLs.

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?

Three short sentences, front-loaded with the action and its destination, then the account scoping, then the input restriction. No filler or restated name/title 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, and the description compensates by stating the return value (a link that opens the project). Combined with full schema coverage, annotation safety hints, and the explicit input constraint, an agent has everything needed to call this correctly.

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 baseline is 3; the description earns above baseline by constraining svg_url ('full-quality Studio99 SVG URLs only', from an earlier generation result), which is a real selection constraint the agent must respect. The text, title, and language parameters gain no additional meaning beyond their schema descriptions.

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 (Creates) and resource (an editable project in the Studio99 design editor) plus the outcome (returns a link that opens it). This clearly distinguishes it from siblings generate_calligraphy and list_styles, which the agent can rule out 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?

The description makes the context clear: it operates on an SVG from 'an earlier generation result' and accepts 'full-quality Studio99 SVG URLs only', implying it is used downstream of generation. It stops short of explicitly naming generate_calligraphy as the source or stating when not to use it, so it is contextual rather than fully prescriptive.

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 well beyond the annotations by disclosing the exact cost (5 credits per call), that credits are drawn from the signed-in user's Studio99 allowance (an auth/account prerequisite the annotations do not convey), and the precise return shape: multiple public PNG URLs, editable SVG vector URLs, and matching Inkora library artworks.

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-loads the core capability and then layers usage, outputs, and cost in a logical order with no filler. It is slightly long at five dense sentences, but each carries distinct 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, the description still explains the return artifacts (PNG and SVG URLs plus library matches) and the credit cost, and it notes the sign-in requirement. For a 5-parameter generation tool this is complete enough 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.

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 text, language auto-detection, mood, style, and use_case. The description reinforces exactness of rendering (conjuncts, matras, ligatures) and gives sample texts, but adds little parameter-level syntax beyond what the schema provides, so the 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 (renders text as calligraphy artwork), names the supported languages and typefaces, and describes the output artifacts. It is clearly distinguishable from the sibling tools create_studio99_project and list_styles.

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 concrete usage contexts (wedding and invitation titles, greetings, names, logos) with examples, and points to the style-listing tool for style ids. It does not state when not to use this tool or compare it against siblings, so it stops short of a full 5.

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 destructiveHint=false, so safety is covered. The description adds value beyond that: 'Read-only and free of charge' plus the cross-tool contract that the returned id feeds the generation tool's style parameter. Doesn't note pagination/limit behavior, but the key behavioral facts are present.

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?

Two tight sentences, zero filler. The primary purpose is front-loaded and the agent-relevant contract (id usage) is placed at the end where it's most action-guiding.

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?

A read-only discovery tool with full schema coverage and no output schema. The description covers purpose, filters, safety, cost, and the downstream id contract, so an agent has everything needed to call it and use the result.

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% and enums are documented, so the schema carries the parameter load. The description still adds framing by naming the exact filter dimensions and the valid language values, reinforcing what to filter on. Baseline 3 is exceeded by this reinforcement.

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 (Lists) and resource (Studio99 calligraphy font styles) with the exact attributes returned (languages, moods, use cases). Clearly distinguishes itself from the write siblings create_studio99_project and generate_calligraphy by being the discovery/listing operation.

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?

Explains filtering conditions ('optionally filtered by language, mood or use case') and routes the agent to the generation tool by noting the id is what 'the generation tool accepts as its optional style value.' Lacks an explicit 'call this before generate_calligraphy' statement, but the relationship is clear.

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