tutoring

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds context about the content covered but does not reveal additional behavioral traits beyond what annotations provide.

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 a single sentence that efficiently lists the key information areas. It is front-loaded with the core purpose and uses minimal words to convey scope.

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?

Given the tool's simplicity (no parameters, no output schema), the description covers all essential aspects of what information the tool provides. It is complete for its intended use.

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 input schema has no parameters, and schema description coverage is 100% (trivially). The description adds no parameter details because none exist, but it clarifies the tool's purpose. Baseline 4 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 clearly states the tool explains how iTutorOnline works, listing specific topics (pricing, free trial, packages, languages, booking, live tutor count). The verb and resource are specific, and it distinguishes from sibling tools that focus on individual tutors or bookings.

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?

While the description does not explicitly state when to use versus alternatives, the context makes it clear that this tool is for general platform information. The list of sibling tools helps differentiate usage, but no explicit exclusions or when-not guidelines are provided.

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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is already established. The description adds meaningful behavioral context by stating that it returns the full public profile and lists exactly what fields are included, plus the flexible identification forms.

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, compact and front-loaded: first states the purpose and payload, second resolves the only open question (how to identify the tutor). Every clause earns its place.

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 description fully covers inputs, output contents, and identifier format. An agent can call it correctly without external context.

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 explains the tutorUserId parameter. The description reinforces the dual identification forms (id from search_tutors or profile handle) but does not add substantial meaning beyond the schema — 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 uses a specific verb plus a clearly bounded resource: 'Get the full public profile for one tutor', and it enumerates the profile fields. This distinguishes it from siblings like search_tutors (listing), get_tutor_reviews (reviews), and prepare_booking (booking action).

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 tells the agent when to call it and how to supply the identifier: use the id from a search_tutors result or the last part of the profile URL. It does not explicitly state when not to use alternative tools, but the context is clear enough for correct selection.

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?

The annotations already establish readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context by clarifying the result includes both written reviews and an average score, though it omits ordering, pagination, and empty-result 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?

One compact sentence states the resource and outcome without filler, and the essential content appears immediately. Nothing in the description is wasted or 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 minimal parameters and annotations covering safety, the description is reasonably complete. It names the expected return content, and the schema fully explains the parameters. Minor gaps are the absence of review ordering, pagination details, and empty-case behavior, but these are not critical for correct selection.

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 have meaningful descriptions: tutorUserId accepts either a search result id or a profile handle, and limit defines range and default. The description adds no extra parameter semantics beyond saying 'for a tutor,' so 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 'get', a clear resource ('recent written reviews and the average score for a tutor'), and differentiates this from sibling tools like search_tutors and get_tutor by focusing on reviews rather than tutor discovery or profile data.

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 when a tutor's reviews are needed, and the parameter description references search_tutors results, but it does not explicitly say when not to use it or name an alternative. The intended context is reasonable, but the guidance is left largely to inference.

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 the description primarily adds the detail that results include search terms and synonyms. No additional behavioral context like pagination or latency is provided, but with zero parameters and safe nature, it's adequate.

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 concise sentences. The first states the function, the second provides usage context. No redundant information. Every sentence serves a purpose.

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?

Given no parameters, no output schema, and comprehensive annotations, the description fully covers the tool's purpose and usage context. It specifies the output includes synonyms, which is valuable for the agent.

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?

There are no parameters; schema coverage is 100%. The description adds value by explaining the output content (subjects with synonyms), which is more than the baseline of 3 for no parameters.

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?

Clearly states the verb 'list', the resource 'subjects tutors teach', and additional details 'with the search terms and synonyms that match each'. Distinguishes from sibling tools like search_tutors and get_tutor.

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?

Explicitly advises using this tool before search_tutors to pick a good subject term, providing clear context for when to use it. Does not mention alternatives or when not to use, but the guidance is specific and helpful.

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, and the description reinforces this by explicitly stating 'Creates nothing and charges nothing itself.' It also discloses the return payload (price estimate, booking brief, link) which is beyond the annotations. This adds useful behavioral context without contradiction.

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 no fluff. The purpose is front-loaded, and the inputs and outputs are concisely enumerated. Every sentence earns its place; this is exemplary structure.

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?

Despite lacking an output schema, the description fully explains what the tool returns (price estimate, booking brief, link) and the flow (human confirms and pays). It covers the key operational aspects, though it doesn't mention potential error cases or prerequisites beyond the required parameter. Given the annotations and schema richness, this is nearly complete.

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 already documents all parameters. The description adds minimal semantic value, only paraphrasing a few inputs ('tutor id, how long, who it is for, optionally a preferred time'). It does not go beyond the schema's descriptions, so the baseline of 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 opens with a specific verb and resource: 'Assemble a real tutoring booking,' and further defines its scope by clarifying it returns a price estimate, booking brief, and confirmation link. It clearly distinguishes from siblings (search_tutors, get_tutor) by focusing on the booking assembly step.

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 when to use it: after selecting a tutor, to prepare a booking for human confirmation. It provides context ('Assemble a real tutoring booking... to finish in one tap') but does not explicitly name alternatives or exclusions. Since siblings are all information-gathering tools, the usage context is clear enough.

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 indicate readOnly=false with a write side effect, and the description adds the practical consequence: the email, and that there is 'no other way to reach them afterwards.' It also discloses a non-obvious return behavior: it returns immediately bookable tutors, not just a confirmation of the handoff. It does not describe post-handoff timing or team response expectations, but the annotation context sets the bar harm modestly.

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?

Purpose, prerequisite, fallback branch, and return hint — four short sentences in decision order, each doing work, none of it redundant. The most important constraints (ask for email, otherwise use search_tutors) are stated directly and early.

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 tool with five simple paramegab no output schema, it covers what the tool does, what input is non-negotiable, when not to use it, and the shape of the result. What remains unspecified is the exact structure of the returned bookable tutors and any expected lateness in the human-tutor follow-up, but these are minor gaps given the simplicity.

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 elevates the required email parameter from a plain field to a decision rule: it must be sourced from the student, never guessed, because it is the only reply channel. That's the kind of parameter meaning that shapes behavior beyond 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?

States a concrete verb and target ('Hand a tutoring request to the iTutorOnline team so they can line up a human tutor'), going well beyond the tautological name and title. It also clearly differentiates from sibling tools: it hands off a request, while the others fetch profiles, reviews, or create bookings.

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 precondition and step: 'ask the student for one before calling this.' Also encodes a conditional fallback to a sibling: 'If they will not share an email, use search_tutors instead and give them a profile link.' That is a true when-to / when-not-to rule with an alternative named.

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 indicate read-only, open-world, non-destructive. Description adds 'verified directory' and 'ranked results' but little extra on pagination or 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?

Three efficient sentences: action, filters, output. No wasted words.

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?

Covers purpose, filters, and return type. Could mention sorting order, but adequate for a search tool without 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 covers 100% of parameters with descriptions. Tool description repeats filter types without adding new information about parameter 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?

Clearly states the tool searches a tutor directory with specific filters and returns ranked results. Distinct from siblings like get_tutor (single tutor) or list_subjects.

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 use for finding tutors but lacks explicit when-not-to-use or comparison with siblings. Mentions list_subjects for subject choices but no further guidance.

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