All4Clinic

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds genuinely new behavioral context: the times are Brasília time, each result carries a booking_url pre-selecting day and time, the human confirms externally with name/e-mail/WhatsApp, and nothing is booked by this call. That is exactly the kind of side-effect clarification an agent needs.

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 sentences, front-loaded with the purpose followed by the booking mechanics; every clause carries information (timezone, URL behavior, confirmation path, no-booking guarantee). Slightly dense but 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?

There is no output schema, so the description must explain the return shape, and it does: a list of open times plus a booking_url per time. Combined with the annotation-backed safety profile, an agent has everything needed to call and interpret this tool.

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 both parameters are described there, including the enum meanings, so the schema carries the load and a 3 baseline applies. The description restates the type semantics but says nothing about the 'from' date parameter (format, default behavior).

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+resource ('find open times') and scopes it to two clearly differentiated purposes, explaining the Portuguese enum values in plain language. Nothing about it could be confused with the sibling tools (list_plans, search_help, read_help_article).

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 clearly explains when to pick each type value ('apresentacao' for clinics evaluating the system, 'treinamento' for clinics already using it) and flags that booking is not done here, implying a separate confirmation step. It does not name an alternative tool or state explicit when-not-to-use 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds that the corpus is the All4Clinic website and that a missing query returns the full answer set. It does not describe answer length or result shape, which is a minor gap given no output schema.

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 sentences, front-loaded with the topic list and followed by the two operational facts (empty query behavior, alternative tool). The first sentence is a long enumeration, but each topic helps an agent judge relevance, so it mostly earns its length.

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 single optional-parameter read tool with no output schema and a closed corpus, the description covers scope, fallback behavior and the sibling boundary. Only the answer format is left implicit, which is acceptable without an 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?

Schema coverage is 100% and already gives keyword examples, so the baseline is 3; the description adds genuinely new meaning by stating the query accepts Portuguese or English keywords and that empty means return all. That bilingual detail is what an agent needs to choose the right search terms.

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 ('answers ... questions a clinic asks before buying') and enumerates the covered topics: LGPD, permissions/audit, multi-unit, apps, signature, payments, AI scope, migration, support. It is clearly distinct from search_help, which it names as the sibling for in-product how-to content.

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 usage boundary: pre-purchase/buyer questions go here, in-product how-to steps go to search_help. It also tells the agent that omitting the query returns everything, so the no-argument path is documented.

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?

With readOnlyHint and destructiveHint=false already set, the description still adds meaningful context by stating that it 'creates nothing' and that the person signs up on the page, clarifying that this tool only retrieves instructions and links. It does not describe the shape of the returned instructions, but the read-only safety profile is already covered by annotations.

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?

One compact sentence, front-loaded with the onboarding purpose, and the key non-side-effect clarification is placed at the end. The parenthetical is slightly dense but every clause carries 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, read-only informational tool with one optional parameter and no output schema, the description covers what information is provided and confirms that no account is created. Nothing essential for correct invocation appears to be 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?

Schema coverage is 100% and the single optional 'plan' parameter is already documented as a plan key from list_plans. The description only reinforces that the link is tailored 'when given', adding little beyond the schema, 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?

The description names the specific informational resource (free trial length, account-creation link, first-day guides) and scopes it to a clinic starting with All4Clinic. It is distinguishable from list_plans through the explicit reference to the chosen plan, though the verb 'get' is implicit rather than stated.

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 onboarding framing and by the pointer to list_plans for the plan key, but there is no explicit when-to-use/when-not guidance against siblings such as search_help or list_help_topics, which could also cover first-day questions.

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 safe read nature is covered. The description adds that output is grouped by area and that a section scopes results, which is useful framing beyond the annotations, though return shape/pagination is not mentioned.

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 action and grouping, then usage triggers, then the parameter tip. The parenthetical area list is slightly long but it earns its place by showing what sections exist.

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 zero-required-param browse tool with annotations covering safety and no output schema, the description gives the agent enough to call it correctly and understand the follow-up workflow. Only the response structure/grouping format is left unspecified.

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 parameter is already documented. The description adds value by explaining that slugs come from a previous call ('Pass a section to see only its guides'), clarifying the intended iterative browse-then-filter workflow.

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 (list) and resource (help-center guides) with clear grouping semantics (by area, with example areas). It explicitly distinguishes itself from read_help_article (pick the right guide before) and implicitly from search_help by being a browse-oriented enumeration.

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 trigger phrases ('what can All4Clinic do?', 'does it have X?') and names the workflow step relative to read_help_article. No ambiguity about when to reach for this over a keyword search.

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 safety is covered. The description adds return-value detail (currency BRL, highlights, inclusions, signup link) and discloses the extra 'recommended_plan' field produced when users/units are supplied — context not available anywhere else since there is no output schema.

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 sentences, both front-loaded: the first enumerates what is returned, the second explains the optional-parameter behavior. No 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?

Without an output schema, the description carries the return-value burden and does so by naming the fields and the derived 'recommended_plan'. A minor gap remains around output shape and whether all plans or only fitting ones are returned.

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 schema documents both parameters. The description nevertheless adds meaning the schema lacks: that users and units are optional and that supplying them triggers computation of the cheapest fitting plan in 'recommended_plan'.

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 All4Clinic subscription plans with monthly price in BRL, highlights, inclusions and signup link. The domain is clearly distinct from help/FAQ siblings, though no sibling is named 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?

Gives clear context: use it to see plans on sale, and pass users/units when the caller wants a fitting recommendation. It doesn't state exclusions or contrast with get_signup_info, but the intended usage 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 cover readOnly/destructive/openWorld, but the description adds genuine behavioral value beyond them: it discloses the conditional return field panel_url and the condition under which it appears ('when the guide names the screen'). This matters because there is no output schema. It says nothing about behavior when the URL is invalid or not a guide, which limits it to a 4.

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 sentences with zero filler; the identity of the resource and its source tool come first, followed by the useful return-field note. Every clause carries 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 single-parameter read-only tool with no output schema, the definition covers what it reads, where the input comes from, and the one non-obvious response field. Nothing an agent needs in order 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?

Schema coverage is 100%, so the baseline is 3, but the description adds a concrete URL format example (https://ajuda.all4clinic.com.br/agenda/agendar) that clarifies what a valid link looks like beyond the schema's 'link returned by search_help'.

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?

Specific verb+resource ('Read the full text of one All4Clinic help guide') with an explicit scope of 'one' guide. It names the sibling search_help as the origin of the input, so the agent can tell it apart from list_help_topics and get_faq.

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 phrase 'given its link from search_help' establishes the prerequisite workflow node and indirectly excludes direct use without a search result. It stops short of stating when NOT to use it (e.g. browsing topics via list_help_topics or answering from get_faq), so no explicit exclusion is given.

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 read-only annotations: it discloses the result cardinality (up to 3 guides), the return fields (title, link, most relevant passage), and an operational instruction for handling panel_url. It also notes the corpus is Brazilian Portuguese while English keywords still work, which the agent cannot know from structured data.

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 primary action and scope, and every sentence carries information (scope, return shape, link handling, escalation). The parenthetical about language and the long topic list make it slightly dense, but nothing is 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?

With no output schema, the description supplies the return shape and the field-level action for panel_url, and it handles the escalation path. An agent has everything needed to call it and to act on 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%, so the baseline is 3; the description raises it by explaining that English keywords are acceptable in addition to Portuguese and by reinforcing the task-oriented query style. It stops short of guidance on query phrasing or multi-concept queries.

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 ("Search the All4Clinic help center") and enumerates the domains covered (scheduling, patients, medical records, finance, inventory, etc.), so an agent can match an intent to this tool immediately. It also names the sibling it is not (read_help_article) for the full-guide case.

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?

Explicit invocation context ("for how to do something in the system") plus a clear routing rule to read_help_article when the snippet is not enough. It does not distinguish the other sibling lookup tools (get_faq, list_help_topics), leaving that boundary to inference.

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