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

Annotations carry the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description is consistent: adding an entry is a write but not destructive. The description adds a return-value contract (confirmation string) and pins meal to four exact values, but does not disclose edge-case behavior such as duplicate entries or invalid mfp_id handling. With annotations doing the heavy lifting, a 3 is appropriate.

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 a one-sentence purpose, followed by a compact Args section and a Returns line. It is appropriately sized for a four-parameter tool with no fluff, though the Args section partially duplicates the nested schema descriptions.

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 diary-add tool, the description covers purpose, the search-first prerequisite, every parameter, and the return format. The main gaps are the lack of explicit routing for update/delete scenarios to sibling tools and no disclosure of failure modes, but these are minor given the annotations and the presence of the 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?

Despite top-level schema coverage being reported at 0%, the description fully documents all four parameters: mfp_id's provenance from mfp_search_food, the exact valid meal values, date format with default, and quantity as a count of default servings. The meal enumeration and the default-serving clarification add genuine meaning beyond the schema's 'e.g.' phrasing.

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 opening sentence states a specific verb and resource: 'Add a food item to your MyFitnessPal food diary for a specific date and meal.' This unambiguously separates it from siblings like mfp_update_food_entry, mfp_delete_food_entry, and mfp_create_food, since the operation (adding an existing food to a diary for a date/meal) is precisely scoped.

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 explicitly establishes the prerequisite workflow: 'You can search for foods using mfp_search_food to find the food ID (mfp_id) needed for this tool.' This tells an agent how the tool fits into a sequence. However, it doesn't explicitly state when not to use it or name alternatives such as mfp_update_food_entry for editing an existing diary entry, leaving some sibling routing 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?

Although annotations already signal mutation and non-idempotence, the description adds essential behavioral context: the resulting mfp_id, the delay before appearing in search, duplicate creation on repeat calls, and the irreversible nature of share_public=True (public foods cannot be edited or deleted). No contradiction with 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?

The description is well structured, front-loaded with purpose and usage, and uses a clear Args list. It is somewhat long and partially repeats parameter information already available in the schema, but the length is justified by the many optional fields and important caveats.

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 create operation with many optional nutrients, the description covers what the agent needs: prerequisites, parameter semantics, defaults, return value (mfp_id), follow-up workflow (mfp_add_food_to_diary), duplicate behavior, and irreversible public submission. Nothing critical for invoking 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?

With schema coverage reported at 0%, the description compensates by listing every parameter with required/optional status, defaults, and the critical rule that all nutrition values are 'PER ONE serving_size' (e.g., serving_size='125 g'). It also clarifies the irreversible meaning of share_public beyond the schema's boolean description.

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: 'Create a new custom food in the MyFitnessPal database (via the v2 API).' It also distinguishes itself from nearby siblings by stating it is for foods where 'mfp_search_food returns nothing suitable' and connects the result to mfp_add_food_to_diary.

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 when-to-use guidance is present: 'Use this when a food is not already in MyFitnessPal (mfp_search_food returns nothing suitable) and you want it available to log.' It names the relevant sibling tools (mfp_search_food, mfp_add_food_to_diary) and warns against repeated calls creating duplicate foods.

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 mark the tool destructive (destructiveHint=true, readOnlyHint=false). The description adds useful behavior beyond that: it confirms deletion is of an existing diary entry, explains the entry_id source, and states the return is a confirmation message containing the deleted entry's name and meal. No contradiction exists.

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 compact, front-loaded with the primary purpose, and organized into a short overview followed by a concise Args/Returns breakdown. Every sentence contributes either to selecting the tool, forming correct arguments, or understanding the result.

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 delete operation, the description is sufficiently complete: it provides the required identifier source, explains optional date behavior, notes the return type, and the destructive nature is already captured by annotations. No critical information needed to call the tool 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?

Although schema description coverage is reported as 0%, the description enumerates both parameters and adds operational meaning: entry_id comes from mfp_get_diary JSON output, and date is optional with a default of today. It complements the schema rather than merely repeating it, though some details are redundant with the nested property 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?

The description opens with a specific verb and resource: 'Delete an existing MyFitnessPal diary entry.' It clearly identifies the object being deleted and points to the prerequisite entry_id source (mfp_get_diary), which distinguishes it from sibling tools like mfp_update_food_entry and mfp_add_food_to_diary.

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 gives clear usage context: the entry_id must come from mfp_get_diary with response_format='json', and date defaults to today. It does not explicitly state when not to use this tool or name alternatives, but the prerequisite and default behavior provide enough guidance for an 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 disclose the full safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), lowering the bar. The description adds some genuinely useful context: the markdown-vs-json output duality and the default-to-today behavior. But most of the prose enumerates return content (meals, entries, nutrition, totals, goals), which the existing output schema already documents, so the incremental behavioral disclosure is modest.

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?

Well-structured and front-loaded: purpose first, then return content, then Args, then Returns. It is slightly redundant — the trailing 'Returns: str: Formatted diary data with meals, entries, nutrition, and goals' restates the second prose paragraph, and the Args block partly mirrors schema descriptions — but at roughly 90 words the length is appropriate for a two-parameter read tool.

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 getter, the description plus the rich annotations (read-only, idempotent, non-destructive, open-world) plus the presence of an output schema give an agent everything needed to invoke it correctly. Minor gaps remain: behavior for dates with no diary entries and timezone semantics for 'today' are unspecified, which prevents a 5.

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 context signal reports 0% schema description coverage (the top-level 'params' wrapper property itself has no description), so the description carries the parameter-documentation burden. Its Args section compensates well: it documents the date format (YYYY-MM-DD), optionality, default-to-today behavior, and assigns semantics to the enum values ('markdown' for human-readable, 'json' for structured data) beyond the bare schema enum.

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+resource ('Get the food diary') with explicit scope ('for a specific date') and content ('all meals and their nutritional information'). The resource is unique among the sibling list — none of mfp_get_measurements, mfp_get_exercises, mfp_get_goals, or mfp_get_water could plausibly be confused with this — so an agent can select it correctly without opening the 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?

Usage context is implied by the purpose statement: an agent can infer this is the tool to call when it needs a full day's diary with meals and nutrition. However, the description gives no explicit when/when-not guidance and never names alternatives, even though siblings like mfp_get_report and mfp_get_food_details overlap in the food-reporting space.

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 safety profile is well covered. The description adds useful context about returning both cardio and strength details and honoring response_format, but it does not go deeper into edge-case behavior or side effects. There is no contradiction with 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?

The main purpose is front-loaded and the Args/Returns sections are clearly structured. Some repetition of schema details keeps it from a perfect score, but the length is appropriate for the tool's simplicity.

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 query tool, the description adequately covers what it returns and the available options. It does not mention empty results or error behavior, but the annotations and schema fill most remaining gaps, so nothing critical 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 the date format, default-to-today behavior, and response_format enum. The description largely repeats this information rather than adding new semantic meaning beyond the schema, so it provides marginal value.

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 gets logged exercises for a specific date, using a specific verb and resource. It further specifies the scope by mentioning both cardiovascular and strength training exercises, making the purpose unambiguous without opening the 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 'for a specific date' phrasing provides clear context for when to use this tool. However, it does not explicitly exclude alternatives or name sibling tools like mfp_get_diary, so there is no when-not-to-use 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful behavioral context by specifying what the response contains, including macros, micronutrients, serving sizes, and the markdown/json output choice. No contradictions with 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?

The description is well organized with a purpose statement, Args section, and Returns section. It is slightly redundant with the input schema, but it remains compact and front-loads the most important usage 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?

Given the read-only annotations and the presence of an output schema, the description covers the operational prerequisites: the source of the MFP ID and the optional response format. An agent has enough information to select and invoke this tool 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?

Despite the low computed schema description coverage, the description still explains both mfp_id and response_format in its Args section. It adds the key detail that mfp_id comes from search results, which is essential for correct use and goes beyond the raw schema type.

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 starts with a specific verb and resource: 'Get detailed nutritional information for a specific food item by its MFP ID.' The MFP ID reference clearly scopes the tool to a lookup-by-ID operation, distinguishing it from sibling search/list 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?

The description states that mfp_id comes 'from search results,' which gives clear workflow context: search first, then retrieve details. It does not explicitly name sibling alternatives or state when not to use this tool, but 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 declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds minor context by mentioning the legacy load_most_used endpoint and stating that the return value is a string list. It does not disclose behaviors like sorting, pagination, or potential latency of the legacy endpoint, but the annotation coverage keeps this 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?

The opening sentence is a clear, front-loaded summary, followed by a scannable Args/Returns structure. The legacy-endpoint sentence adds context but is not essential. Overall, the description is compact and readable without significant bloat.

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?

The tool is simple, read-only, and has an output schema, so the description is nearly sufficient for invocation. It covers both parameters and the return type. The main gaps are the lack of sibling-tool routing and the untold default behavior for response_format and limit, leaving some ambiguity for an agent choosing between similar list tools.

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 reported as 0%, so the description carries the burden of explaining parameters. It documents both limit and response_format, adds a domain-specific default of 10 for limit not present in the schema, and lists valid response_format values. This meaningfully compensates for the schema gap, though it omits the markdown default for response_format.

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 operation: 'Get most-used foods from MyFitnessPal,' with a specific verb and resource. It also names the legacy endpoint backing it. However, it does not explicitly distinguish itself from sibling tools such as mfp_get_recent_foods and mfp_get_my_foods, so it stops short of full differentiation.

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?

There is no guidance about when to use this tool versus alternatives like mfp_get_recent_foods or mfp_get_my_foods. The phrase 'most-used foods' implies a use case, but the description never states when to prefer this tool, when not to, or what distinguishes 'frequent' from 'recent' or 'my foods.'

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 carry readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the tool returns 'configured daily targets' for 'all tracked nutrients,' which clarifies it reports existing settings rather than computing values. It does not discuss auth, rate limits, or edge cases, but coverage is adequate for a simple read 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 opening two sentences are clear and front-loaded. The subsequent `Args:` and `Returns:` blocks duplicate information already present in the input schema and output schema, so they add length without much new signal. Appropriately sized overall, but not maximally lean.

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 read-only single-parameter tool with rich annotations and an output schema, the description is sufficient: it identifies the resource, defines the optional date parameter, specifies response_format choices, and states what the return value describes. No critical information needed to invoke the tool correctly is missing. It would be complete even without the redundant schema duplication.

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 reported as 0% at the wrapper level, so the description compensates by listing `date` with its optionality and format/default and `response_format` with its allowed values. This gives an agent the parameter semantics needed to call the tool correctly. It largely restates schema details rather than adding new meaning, so it is functional but not exemplary.

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+resource ('Get the user's daily nutrition goals') and enumerates the nutrient categories (calories, protein, carbs, fat). It clarifies the return scope as 'configured daily targets for all tracked nutrients,' which distinguishes it from siblings like mfp_get_diary or mfp_set_goals. Even without naming alternatives, the resource is unambiguous.

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 use whenever the user's daily nutrition goal targets are needed, and it clearly denotes a read operation. It does not explicitly name alternative tools or state when not to use it, leaving the agent to infer routing from the resource name. No exclusions or sibling comparisons 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds that data is 'historical measurement data with dates and values,' but it does not disclose additional behavior like ordering, units, missing-data handling, or how response_format changes the output beyond the 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?

The description is compact and front-loaded with the core operation, followed by a clear Args/Returns block. The 'Useful for tracking...' sentence is slightly extra but provides legitimate use-case context. Overall, it is efficient and easy to scan.

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 retrieval tool, the description plus annotations and output schema provide enough information to call the tool correctly: what it returns, the date-range semantics, parameter names/defaults, and output format options. It does not discuss error behavior or all possible measurement names, but those are not critical for basic invocation.

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?

Given the context signal of 0% schema description coverage, the description carries the burden of documenting parameters. It explicitly lists measurement, start_date, end_date, and response_format with defaults and value options. This compensates for the coverage gap, though it does not add edge-case semantics beyond what the schema already implies.

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: 'Get body measurements (weight, body fat, etc.) over a date range.' This clearly states what the tool does and distinguishes it from siblings like mfp_set_measurement and mfp_get_diary without requiring the reader to inspect the 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 provides a clear use case: 'Useful for tracking weight loss progress and body composition changes.' This gives the agent contextual guidance on when to choose this tool. However, it does not explicitly mention alternatives or when not to use it, such as using mfp_set_measurement for writing measurements.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds value beyond those annotations by disclosing that this tool relies on a legacy endpoint and remains reachable when the modern page redirects away from authenticated sessions. No contradiction with 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?

The description is well-structured: a one-sentence purpose, a brief endpoint explanation, then clearly labeled Args and Returns sections. It is compact and front-loaded, with no filler, though it does partially repeat parameter details already present in the schema.

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 read-only tool with annotations and an output schema, the description provides sufficient context: endpoint provenance, authentication scope, parameter meaning, and return type. It could be slightly more complete by mentioning explicit error or authentication caveats, but these are implied by 'authenticated user.'

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 description explicitly documents limit with its effective default of 100 and maximum of 100, and lists response_format options as 'markdown' or 'json'. Even though the nested schema provides some field descriptions, the tool description adds practical constraints and clarifies expected usage.

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 and resource: 'Get foods created or saved by the authenticated user.' It also names the underlying legacy endpoint, making the tool's scope clear and distinguishing it from general food search or food-detail 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?

The description explains a useful practical context: it uses the legacy endpoint that remains accessible even when the modern My Foods page redirects. However, it does not explicitly name sibling tools or provide when-to-use/when-not-to-use guidance relative to mfp_get_recent_foods, mfp_get_frequent_foods, or mfp_search_food.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by noting the legacy endpoint still works when newer account pages redirect away from authenticated sessions, which is useful operational information not present in the annotations or 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?

The description is compact and well-structured: one purpose sentence, one technical context sentence, a terse Args list, and a Returns line. There is no filler, and the most important information is 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?

For a read-only list tool this is mostly adequate, covering parameters, return type, and a reliability caveat. It is incomplete as a selection aid because it never addresses when to use this tool instead of the nearby recent/frequent/my-food siblings, and the limit default discrepancy leaves some ambiguity for correct invocation.

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 Args section repeats and clarifies limit and response_format, including the effective default of 10 and max of 100, which adds some meaning beyond the schema's null default. However, the stated default 10 conflicts with the schema's declared default of null, and the response_format values are already enumerated in the schema, so the added parameter insight is only partially reliable.

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?

Begins with a specific verb and resource: 'Get recently used foods from MyFitnessPal.' The phrase 'recently used' distinguishes it from sibling tools like mfp_get_frequent_foods and mfp_get_my_foods, so an agent can tell this tool apart without needing to inspect schemas.

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?

No explicit guidance on when to choose this tool over siblings such as mfp_get_frequent_foods, mfp_get_my_foods, or mfp_search_food. The legacy-endpoint remark is an implementation detail rather than a selection rule, and no exclusions or alternative conditions are 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 establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral detail beyond that by explaining that the tool returns daily values plus summary statistics and supports markdown or JSON response formats, with no contradiction to 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?

The description is well structured with a purpose statement, usage note, Args list, and Returns section. It is mostly economical, though 'over a date range' appears in both the first and second sentences, creating minor redundancy.

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?

The description together with the schema covers the tool's inputs, defaults, response format, and return contents. It does not enumerate all valid report_name values or describe behavior for invalid or empty date ranges, which are useful but not critical gaps for a simple read-only report 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?

Despite the top-level schema description coverage signal of 0%, the description compensates by documenting all four parameters: report_name, start_date, end_date, and response_format, including defaults and examples. It could be stronger by listing all valid report names and clarifying date range edge cases, but it covers the required semantics.

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 identifies a specific action: retrieving a nutrition report over a date range and returning daily nutrient values. It distinguishes this from diary lookup or measurement tools through the 'report' and 'date range' framing, though it does not explicitly name a sibling alternative.

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 statement 'Useful for analyzing trends and patterns in nutrition intake' gives clear situational guidance for when to use this tool. However, it does not explicitly state when not to use it or name alternative tools such as mfp_get_diary, so it provides context but no exclusions.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: one entry per day, null steps for days without synced data, and a hard 31-day-per-call range limit — all things the annotations cannot express.

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 one-line purpose, then constraints, then args and returns in a scannable Google-style docstring. Minor redundancy between the prose line about per-day entries and the Returns section, but nothing that wastes an agent's attention.

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-param read tool with an output schema present, this covers purpose, defaults, null semantics, and the range cap — enough to call it correctly. It stops short of mentioning error behavior when the 31-day limit is exceeded, but that is a minor 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?

Top-level schema description coverage is 0% (the single `params` wrapper is undocumented), so the description must compensate, and it does: it enumerates start_date, end_date, and response_format with their defaulting rules (6 days back, today). It adds meaning beyond the schema even though it does not restate the YYYY-MM-DD pattern.

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+resource ('Get daily step counts') and even names the upstream source ('synced into MyFitnessPal, e.g. from Apple Health'), which disambiguates it from generic measurement or diary siblings. An agent can distinguish this from mfp_get_measurements or mfp_get_diary without opening the 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?

Usage is implied by the resource name, and the 31-day range cap tells the agent when the call will fail, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. for manually logged vs synced steps). Adequate but leaves routing 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 cover readOnly, idempotent and non-destructive, so the bar is lower, but the description adds real value by disclosing that the value is always in milliliters regardless of the account's display unit and explaining why (the underlying `/food/water` field is `milliliters`). That is exactly the kind of context an agent would otherwise get wrong; it does not cover error behavior or what happens with future dates.

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 operative statement is front-loaded in the first sentence, and the endpoint rationale earns its place by justifying the milliliter guarantee. The reference to python-myfitnesspal's `_get_water` is slightly indulgent but short enough not to distract.

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?

An output schema exists, so return formatting need not be spelled out, and the one genuinely ambiguous aspect — the unit — is explicitly resolved. A brief note on whether future dates or missing entries return zero versus an error would make it fully complete for a single-param read 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?

With one parameter, the description restates the YYYY-MM-DD format and the default-to-today behavior, which largely duplicates the schema's own `date` description. It does not explain the required `params` wrapper object, so it adds only marginal meaning beyond the structured field.

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 first sentence gives a specific verb and resource ('Get water intake') plus the scope ('for a specific date'), which cleanly separates it from mfp_set_water and the broader mfp_get_diary. It never names a sibling tool explicitly, so it stops short of full differentiation.

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: the reader infers this is the read-side counterpart to mfp_set_water. There is no explicit 'use this when...' statement, no mention of when to prefer mfp_get_diary instead, and no prerequisites or auth notes.

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, idempotent, and non-destructive behavior. The description adds that the tool searches the external MyFitnessPal database and returns a list with specific fields, which is useful. It does not disclose potential rate limits, network dependency, or error behavior, but for a read-only search this is a moderate gap rather than a serious one.

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 well-structured and efficient: a one-sentence purpose statement, a concise return summary, and a clean Args/Returns breakdown. There is no filler, and the bulleted parameter list earns its place given the low schema coverage.

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?

The description covers the invocation pattern, all parameters, and the return value. Combined with readOnly/idempotent annotations and a likely output schema, it is nearly complete for a search tool. The only missing piece is explicit guidance on when to prefer this tool over sibling search/list tools.

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?

Even though schema description coverage is reported as 0%, the description fully compensates by documenting every parameter with types, examples, and defaults: query with example, limit with default of 10, and response_format with 'markdown' or 'json'. This is more than enough for an agent to construct a correct 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?

The description uses a specific verb and resource: 'Search the MyFitnessPal food database for food items.' It also clarifies the output type (list of matching foods) and mentions MFP ID, which helps distinguish it from detail-lookup tools like mfp_get_food_details. However, it does not explicitly contrast with user-specific list tools like mfp_get_my_foods or mfp_get_recent_foods, so it stops short of a full 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 description makes the primary usage clear: search the food database when you need to find foods by query. It also hints at a follow-up workflow ('which can be used with mfp_get_food_details'), giving useful context. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for a search tool.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds important behavioral detail: it performs partial updates, leaves unspecified values unchanged, and returns a confirmation message. This is meaningful context that helps the agent predict side effects.

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 well-structured and front-loaded with the main purpose. The Args and Returns sections are useful, though there is minor redundancy between 'Update daily nutrition goals' and 'Sets new daily targets for the specified nutrients.' Overall it is appropriately sized with no significant waste.

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 annotations, schema, and output schema, the description covers the essential semantics: what the tool updates, the partial-update behavior, the parameter list, and the return type. It does not mention validation ranges or alternatives to sibling tools, but those are either in the schema or not critical for invoking this tool 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?

The description enumerates all four nutrient parameters with their types and units, which compensates for the low reported schema coverage. The schema itself also documents ranges and examples. The description adds the key semantic that only provided values are updated, making the parameter behavior clearer.

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 identifies the action ('Update daily nutrition goals') and the resource (calories, protein, carbs, fat), with a specific verb and target. It does not explicitly name sibling tools like mfp_get_goals, but the wording is specific enough to avoid confusion with the measurement, water, or food-entry 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?

The description gives clear context for use: updating daily nutrition targets, with partial-update behavior ('Only updates the values that are provided; others remain unchanged'). It does not explicitly state when not to use this tool or point to alternatives such as mfp_get_goals, so it stops 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 establish that this is a non-read-only, non-idempotent, non-destructive operation. The description adds that it records a value in MyFitnessPal and returns a confirmation, but it does not clarify whether repeated logging of the same measurement creates duplicates or overwrites an existing entry — a meaningful side-effect for a 'set_measurement' 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?

Short and front-loaded, with clearly labeled Args and Returns sections. The second sentence is somewhat redundant with the first, but overall the structure is efficient and scannable.

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?

The description covers the action, key inputs, and return type, and the annotations plus nested input schema fill in the safety and parameter details. The main missing pieces are duplicate/overwrite behavior and a richer list of valid measurement types, but these do not block correct invocation for the common case.

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 description lists both parameters with a default and an example, which is helpful given the low schema description coverage signal. However, it does not enumerate valid measurement type strings or specify units beyond the 185.5 example, so some inference is still required.

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?

Begins with 'Log a new body measurement...' — a specific action, object, and time scope ('for today'). This clearly distinguishes it from sibling read tools like mfp_get_measurements and from goal/water/food 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?

The description explicitly states when to use the tool: to log a new body measurement for today. It does not mention exclusions or point to alternatives such as mfp_get_measurements for retrieving measurements, but the intended use 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?

Adds genuinely useful behavior beyond the annotations: the value replaces rather than accumulates the day's total, and the ml/cup conversion factor is spelled out. This is the critical fact an agent needs before calling, since destructiveHint=false might otherwise suggest an append. Minor tension: a total-replacing set is naturally idempotent, yet idempotentHint=false is declared, which the description does not reconcile.

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 operation and its key replace-semantics before the Args/Returns scaffolding, and no sentence is filler. The Args section duplicates schema text, costing a little density, but the structure is easy to scan.

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?

An output schema exists, so the brief Returns line is sufficient, and the mutation semantics are covered. The remaining gap is conflict handling between the two interchangeable unit fields and any permission or failure behavior for an openWorld write, neither of which is addressed.

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 Args block enumerates all three fields with types, defaults, and format, which compensates for the reported low schema description coverage. However, the wording largely restates what the schema already says ("Preferred", "Replaces the day's total", the 236.588 factor), so it adds little new meaning. It never states what happens when both milliliters and cups are supplied, which is the one precedence question the schema does not answer either.

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 ("Log water intake") plus the scope ("for a specific date") and immediately clarifies the write semantics with "Sets the day's total water." Against siblings that are all mfp_get_* readers, an agent can tell this is the write counterpart without opening either 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?

Usage is implied rather than stated: the agent learns it should supply milliliters or cups, but there is no explicit when-to-use vs when-not guidance, no mention of verifying with mfp_get_water first, and no note on prerequisites such as an authenticated session. The tool's purpose is obvious enough that this is adequate but leaves routing 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?

Beyond the annotations, it discloses a non-obvious behavior: MyFitnessPal may rewrite an entry during edit and return a replacement row, with current_entry_id and entry_id_changed to track the right row. This directly prepares the agent for a shifted identity, which is valuable for a mutation 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 front-loads the core purpose, then adds the important rewrite caveat, followed by a scannable bullet list of parameters and a short Returns line. Every sentence earns its place and the layout supports quick parsing.

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 update operation with a potential entry-id change, the description provides the necessary source-of-truth workflow, all editable fields, and return semantics. The agent has enough context to locate the entry_id, make the desired change, and handle the possible replacement row.

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 description covers all six parameters in its Args section and adds meaning: entry_id comes from mfp_get_diary JSON output, date defaults to today, unit is a serving-size label, and weight_id is a raw MFP option ID. With schema coverage reported at 0%, it carries much of the semantic load, though it omits some nuances like weight_id overriding unit and constraints on quantity.

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 precise verb+resource phrase: 'Update an existing MyFitnessPal diary entry,' and enumerates what can be changed (meal, quantity, serving size, date). It also names mfp_get_diary as the source of entry IDs, which helps distinguish it from add/create/delete 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?

It clearly states the prerequisite—entries previously returned by mfp_get_diary—and tells callers to use response_format='json' to obtain the required entry_id. It gives strong contextual guidance for when this tool applies, though it does not explicitly list exclusions or alternative tools.

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