Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FatSecret MCP Server Search for 'quinoa' and show its nutrition facts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An independent Python MCP server backed by the fatsecret package. It exposes
the supported FatSecret Platform API separately from experimental member-site
recipe, diary, and RDI operations.
This project has independent source code and Git history. Compatibility tool names were transcribed from a pre-existing public tool list; no implementation, schemas, configuration, tests, or architecture were copied from that project.
Run the current GitHub version with a fresh dependency resolution at each MCP server start:
uvx --refresh --from git+https://github.com/ChocoTonic/fatsecret-mcp-server \
fatsecret-mcp-server --profile defaultuvx --refresh is the update mechanism. The running server does not rewrite
its own executable or dependency environment. Each server release constrains
the reviewed fatsecret backend. Official food reads prefer the latest
reviewed method and cache the newest version accepted by the configured
account; only upstream error 10 triggers an older-method fallback.
Related MCP server: Food Facts MCP Server
Platform credentials:
export FATSECRET_CONSUMER_KEY=...
export FATSECRET_CONSUMER_SECRET=...
export FATSECRET_ACCESS_TOKEN=... # required for user-scoped tools
export FATSECRET_ACCESS_SECRET=...
export FATSECRET_ACCOUNT_ID=... # stable account label for mutationsMember recipe, diary, and RDI credentials:
export FATSECRET_USERNAME=...
export FATSECRET_PASSWORD=...Credentials may instead be stored in the operating-system keyring. Credential
tools are disabled unless FATSECRET_MCP_ALLOW_CREDENTIAL_TOOLS=true and should
only be exposed temporarily through the bootstrap profile.
Profiles are default, member, discovery, diary, bootstrap, and full.
The capability resolver is present in every profile. It can execute only an
explicitly reviewed read allowlist permitted by the active profile, without
advertising every backend schema. Resolved writes and authentication metadata
are blocked.
Every resource mutation requires an idempotency key. Reuse the same key after a timeout; using it for a different payload is rejected. Recipe-copy resumes use their durable operation ID as the idempotency identity. Ambiguous outcomes are retained as unknown and must be reconciled before another write.
Durable state is namespaced by a one-way account identifier. Account writes are serialized across server processes, and the state directory, database, and lock files are restricted to the current operating-system user.
Recipe ingredients use a known FatSecret food_id. Omit portion_id for grams,
or first call list_member_food_portions to select an exact opaque portion ID.
The member website stores gram quantities as whole numbers; fractional grams
are rejected before writing.
Member diary tools accept both foods and owned recipes. Omit portion_id to
select grams when available or the sole recipe serving. Website portion IDs
-1 (grams) and 0 (owned recipe serving) are valid here and intentionally
remain separate from official API serving IDs. Recipe diary entries snapshot
nutrition, so delete and re-add affected diary entries after recipe changes.
Member recipe, diary, and RDI operations automate unsupported FatSecret website forms and can break when that website changes.
See architecture and the tool inventory.
Add a food diary entry once, keyed by a durable idempotency value.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| meal | Yes | ||
| food_id | Yes | ||
| serving_id | Yes | ||
| food_entry_name | Yes | ||
| idempotency_key | Yes | ||
| number_of_units | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate idempotency and non-read-only behavior. The description usefully adds that the idempotency is 'durable' and 'keyed by' a value, giving the agent a clearer model of how duplicate calls are handled. 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 a single, tightly written sentence with no filler. The core action and key constraint are 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?
Despite having an output schema and annotations, this is a write operation with seven parameters and zero schema-level descriptions. The description leaves out essential usage context, parameter relationships, and duplicate-handling outcomes, so the agent has too much to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at the idempotency_key semantics. It does not clarify what food_id, serving_id, number_of_units, meal, or date mean beyond their names and schema types.
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 a specific action ('Add') and a specific resource ('food diary entry'), and clarifies the idempotent nature ('once, keyed by a durable idempotency value'). This clearly distinguishes it from the sibling read-only tools like get_user_food_entries and search_foods.
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: this is the tool that adds a food entry, while siblings are mostly retrieval tools. However, there is no explicit guidance about when not to use it or how it relates to alternatives such as updating or deleting entries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report which credential sets are configured without exposing values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation and adds the nuance that it reports configuration status without exposing values. While the annotation already indicates read-only behavior, the description reinforces the non-destructive nature and clarifies that sensitive data is not returned.
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 conveys the essential purpose without extraneous detail. It is well-structured and front-loads the action and object, making it easy to parse.
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, a single clear purpose, and an output that is self-evident—the description fully covers what an agent needs to know to invoke it correctly. There are no hidden side effects or complex return values to document.
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 tool has no parameters, so there is nothing for the description to elaborate on. The schema is empty, and the description does not need to add any parameter-related meaning.
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 ('Report') and clearly identifies the resource ('credential sets') and the action (checking their configuration). It unambiguously distinguishes the tool's purpose from potential siblings that might modify or retrieve credentials.
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 what the tool does but provides no guidance on when to use it versus alternatives. There is no mention of conditions, contexts, or exclusions, leaving the agent to infer appropriate usage from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a food by ID using the latest endpoint available to the account.
| Name | Required | Description | Default |
|---|---|---|---|
| food_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is covered. The description adds some context by noting that the endpoint selected depends on what is available to the account, which hints at variable behavior. However, it does not explain potential errors, authentication requirements, or how the response might differ across endpoints.
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 with the core operation front-loaded: 'Get a food by ID.' The trailing clause about the latest endpoint is slightly vague and arguably unnecessary, but it does not bloatt the description significantly.
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 that there is an output schema, annotations covering read-only and non-destructive behavior, and only one required parameter, the description is reasonably complete for a simple getter. It lacks explicit guidance about handling unknown IDs or when to prefer search_foods, but the tool's simplicity and structured metadata compensate for these omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the single parameter food_id is self-evident from its name, type, and exclusiveMinimum constraint. The description reinforces that this tool fetches by ID but adds little meaning beyond what the schema already exposes. For such a simple parameter, this is adequate but not exceptional.
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 verb-resource operation: retrieving a food by its ID. This distinguishes it from sibling tools like search_foods, which likely find foods by criteria. The clause 'using the latest endpoint available to the account' adds some ambiguity about which endpoint is actually used, but it does not obscure the primary purpose.
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 explicit guidance about when to use this tool versus alternatives such as search_foods. The description implies that you need a food ID, but it never explicitly says 'use this when you already have a food_id' or directs users to search_foods when they don't. The endpoint-version mention suggests account-dependent behavior but does not provide decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one public recipe by exact recipe ID.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 covered. The description adds that the recipe is 'public' and that lookup is by exact ID, but it does not disclose error behavior or what happens when the ID is not found. Given the annotations, this is adequate but not rich.
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 concise sentence with no wasted words. It front-loads the core action ('Get'), the scope ('one public recipe'), and the key constraint ('exact recipe ID').
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 low complexity, one simple parameter, a read-only annotation, and an output schema, the description covers everything essential for correct invocation. No additional context about return values is needed because an output schema is present.
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 already defines recipe_id as a required integer greater than zero. The description adds the meaningful semantic that this is an exact ID match, not a fuzzy or partial search, which helps an agent pass the correct value. For a single, well-constrained parameter, this is sufficient compensation for the 0% schema description coverage.
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 ('Get') with a clear resource ('one public recipe') and a precise lookup criterion ('by exact recipe ID'). It clearly distinguishes this tool from siblings like search_recipes, since it targets a single recipe by exact ID rather than a search query.
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 'by exact recipe ID' clearly implies this tool should be used when the caller already has a specific recipe ID, which is useful context for choosing between this and search_recipes. However, it does not explicitly name the alternative or state when not to use this tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get authenticated food diary entries by epoch-day or entry ID.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| food_entry_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Get' is consistent with that. The description adds useful behavioral detail: the entries are scoped to the authenticated user and are retrievable by date or entry ID. 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?
A single front-loaded sentence contains the verb, resource, and access paths with no filler. Every word contributes.
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 an output schema and readOnly/destructive annotations, the core calling information is present. The main gap is the missing clarification of the date/ID selection semantics; otherwise an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning by explaining that 'date' is an epoch-day and that 'food_entry_id' is an entry ID, but it leaves the relationship between the two parameters unclear: both are optional and default null, and the description does not state whether one must be supplied or what happens if both are provided.
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 a specific verb ('Get'), a specific resource ('authenticated food diary entries'), and the two access paths ('epoch-day or entry ID'). This distinguishes it from siblings like search_foods/get_food and add_food_entry without needing to open their 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?
The description makes the resource scope clear, so an agent can infer it is for retrieving the current user's diary entries rather than searching the food database. However, it gives no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as get_weight_month or add_food_entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated Platform user's profile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive behavior. The description adds the valuable context that this is specifically the authenticated user's profile, which sets expectations about data scope. No annotation 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 a single clear sentence with no filler. It states the action and the target resource directly, making it easy for an agent to process quickly.
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-parameter, read-only tool with an output schema, this description is complete. The annotations cover safety behavior, and the description covers scope; nothing essential is missing 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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the empty schema is consistent with a simple profile lookup.
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 ('Get') and a specific resource ('the authenticated Platform user's profile'). This clearly distinguishes the tool from siblings like check_auth_status, which would return authentication state rather than the profile itself.
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 this tool should be used when the current user's profile is needed, but it does not explicitly state when to use it versus alternatives such as check_auth_status. No exclusions or alternative routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get authenticated weight records for the month containing an epoch-day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds useful behavioral context by noting that the records are 'authenticated' and by explaining the date interpretation rule: the whole month containing the given epoch-day is returned. It does not address null-date behavior, but that is not a safety concern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the verb and resource, with no filler or redundant detail. Every word contributes to understanding the tool's behavior.
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 one-parameter, read-only tool with an output schema provided, the description is nearly complete. The only meaningful gap is that the behavior when 'date' is null is left implicit.
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 0%, but the description compensates by giving meaning to the 'date' parameter: it is an epoch-day used to select a month. It still leaves the null-default case unexplained, so it is not quite a 5.
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 ('Get') plus a resource ('authenticated weight records') and a precise scope ('for the month containing an epoch-day'). This naturally distinguishes it from sibling tools like search_foods or get_user_food_entries.
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 sentence clearly implies when to use this tool: whenever weight records for a month are needed. However, it gives no explicit guidance about when not to use it or how it relates to alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find latest backend operations and optionally execute one safe read.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| execute | No | ||
| arguments | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's 'safe read' aligns with the readOnlyHint=true annotation and adds a slight behavioral qualifier. However, it does not disclose what 'latest' means, whether the resolved search results are cached/dynamic, or what happens when execute=true. Annotations already cover the safety profile, so the description adds only minimal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, but brevity here comes at the cost of essential information. It does not front-load any parameter semantics or usage guidance. A single vague sentence is not 'appropriately sized' when the tool has multiple parameters and no 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 tool with 3 parameters, 0% schema description coverage, and a somewhat abstract purpose, the description is woefully incomplete. It does not explain how to express a need, what operations can be resolved, or what 'execute' entails. Although an output schema exists, the description still fails to give the agent enough context to call the 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?
Schema description coverage is 0%, so the description must compensate by explaining the three parameters: need, execute, and arguments. The description does not mention any of them or how to construct them. There is no semantic information about what 'need' should contain or how arguments are formatted, leaving an agent completely without guidance.
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: 'Find latest backend operations and optionally execute one safe read.' It does give a general sense of the tool's role as a meta-interface to backend operations. However, 'backend operations' is vague, and it does not clearly distinguish this tool from the sibling data-access tools beyond implying it is a discovery/routing tool.
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 the direct sibling tools like get_food or search_foods. The description does not mention prerequisites, when to set execute=true, or when to call the siblings directly instead. The use case is implied but never stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search foods with the latest Platform endpoint available to the account.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| query | Yes | ||
| region | No | ||
| language | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds only the 'latest Platform endpoint' nuance without explaining implications such as varying result formats or pagination. This added context is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler words. It clearly front-loads the verb and object while packing the endpoint nuance into the qualifier. Every word 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?
With five parameters and zero schema descriptions, the tool description leaves major gaps: no guidance on pagination, region/language usage, endpoint version differences, or when this search is preferred over get_food. The output schema reduces the need to explain returns, but the input semantics and selection criteria remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain query, page, limit, region, or language semantics. Parameter names and constraints are somewhat self-explanatory, but the description provides no additional meaning to compensate for the low coverage.
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?
Description states the specific action 'Search' and target resource 'foods', distinguishing it from sibling search_recipes and get_food. The qualifier 'with the latest Platform endpoint available to the account' adds context but is slightly vague about what that endpoint actually changes.
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 guidance is given on when to use search_foods versus alternatives like search_recipes or get_food. The description does not mention exclusions, prerequisites, or scenarios where a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public recipes using the latest reviewed Platform endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| query | Yes | ||
| region | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds that only public recipes are searched, but it does not disclose pagination behavior, region handling, or endpoint specifics beyond that. 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 short and front-loaded with the essential action: 'Search public recipes'. The trailing phrase 'using the latest reviewed Platform endpoint' is somewhat vague and not clearly informative, but the overall structure is easy to parse and wastes little space.
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 search tool with an output schema and annotations covering safety, the description is minimally viable. However, it lacks parameter semantics and any comparison to sibling search tools, making it incomplete for an agent that needs to know when to choose this tool and how to phrase its arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the four parameters (query, page, limit, region). The agent gets no explanation of their meaning, how they interact, or how region affects the search, leaving the schema titles and constraints as the only source of information.
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 clear verb ('Search') and a specific resource ('public recipes'), making the tool's basic purpose understandable. However, it doesn't explicitly contrast with sibling search tools like search_foods or get_recipe, and the phrase 'latest reviewed Platform endpoint' adds little concrete meaning.
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 no guidance on when to use this tool versus alternatives such as search_foods or get_recipe. There are no exclusions, prerequisites, or contextual conditions, so an agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0add_food_entrycheck_auth_statusget_foodget_recipeget_user_food_entriesget_user_profileget_weight_monthresolve_fatsecret_capabilitysearch_foodssearch_recipesScored across 10 tools
Each domain tool has a clear target resource and action, so search_foods, get_food, search_recipes, and get_recipe are easy to separate. However, resolve_fatsecret_capability is a broad meta-tool that can optionally execute a safe read, creating mild overlap with the read operations.
All tool names follow a consistent lower_snake_case verb_noun pattern, such as search_foods, get_recipe, add_food_entry, and get_weight_month. The naming is predictable and makes the toolset easy to navigate.
With 10 tools, the server is well-scoped for a nutrition and food-tracking API. It covers auth, food search, recipe search, user profile, diary entries, and weight without feeling bloated or sparse.
Core workflows like searching foods/recipes, viewing profiles, adding food entries, and reading weight are present. However, there is no update/delete operation for food diary entries and no way to write weight records, which are notable gaps in a logging/tracking domain.
Scraps Kitchen gives any AI agent a persistent, household-aware kitchen memory. Unlike generic chatbot recall, Scraps maintains structured cooking data: what's in your fridge (with freshness tracking), who you cook for (with allergens, dietary restrictions, and preferences), your recipe collection (with cook notes and per-diner ratings), your shopping list, and your kitchen equipment. 27 tools across 6 domains let agents read kitchen context, suggest meals that respect dietary safety, update the pantry after cooking, and build a history of what works for your household. Every interaction makes the data richer. Cooking history, preference signals, kitchen awareness = better suggestions next time. All tools work via oAuth and a free scraps.kitchen account.
Broad, OAuth-protected provider and financial-domain API tools for research agents.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
