Find free ready-made PriorStates Studio apps for everyday needs: expenses, receipts, chores, RSVPs.
Scored across 4 tools
Each tool has a clearly distinct role: find_apps searches by plain-language need, list_apps browses the full catalog by group, get_app retrieves full details for one id, and get_studio explains the product and platform links. The find/list boundary is clear because one is semantic matching while the other is exhaustive grouped browsing.
All four tools follow a consistent snake_case verb_noun pattern: find_apps, get_app, get_studio, list_apps. There are no mixed conventions or vague verbless names.
Four tools is well-scoped for a free-app gallery server covering discovery, browsing, detail lookup, and product/platform information. Each tool earns its place without redundancy.
The surface covers the core gallery lifecycle: find, list, inspect, and learn about the Studio. A minor gap is the absence of any explicit create/make-app operation despite find_apps mentioning that Studio can build a new app from a description.
Find free ready-made PriorStates Studio Gallery apps for a need described in plain words, in English, Chinese, Spanish or Portuguese (e.g. 'split a dinner bill', 'keep my receipts for taxes', '分账', 'recibos'). Returns the best matches with what each does, a page link, a screenshot and how to open it. If nothing fits, Studio can make a new app from the description.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What the person wants to do, in their own words. | |
| limit | No | How many apps at most (1-10, default 3). | |
| language | No | Language for the reply's app text and links: en, zh (Simplified Chinese), zh-hant (Traditional Chinese), es, pt. Default en (zh when the need is written in Chinese). |
| Name | Required | Description |
|---|---|---|
| apps | Yes | |
| need | Yes | |
| language | Yes | |
| make_new | No | |
| confident | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety bar is met; the description adds useful behavior the annotations don't cover — multilingual matching and the no-match fallback to Studio app creation. It does restate return contents that the output schema already documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with embedded examples; the enumeration of return contents (what each does, link, screenshot, how to open) is slightly redundant given the output schema exists, but overall there is little 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?
For a 3-parameter read tool with full schema coverage, annotations and an output schema, the description covers purpose, language scope and the no-results path. The only meaningful omission is an explicit pointer to which sibling to call when the task is enumeration or single-app lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description earns extra credit by illustrating the free-text `need` parameter with real multi-language examples ('split a dinner bill', '分账', 'recibos') and by noting the language default shifts to Chinese when the need is in Chinese.
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 ('Find free ready-made PriorStates Studio Gallery apps') scoped to a plain-language need, which clearly separates it from get_app (single app) and list_apps (enumeration) among the 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?
Gives concrete examples of the kind of need to pass and an explicit fallback condition ('If nothing fits, Studio can make a new app'), which implicitly routes to get_studio. It never names the sibling tools or states when to prefer list_apps/get_app instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details of one PriorStates Studio Gallery app by id (from find_apps or list_apps): what it does, what it needs (permissions in plain words), its page, screenshot and how to open it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | App id, e.g. expense-split. | |
| language | No | Language for the reply's app text and links: en, zh (Simplified Chinese), zh-hant (Traditional Chinese), es, pt. Default en (zh when the need is written in Chinese). |
| Name | Required | Description |
|---|---|---|
| app | Yes | |
| needs | Yes | |
| how_to_get | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a safe, idempotent, read-only lookup, so behavioral burden is low. The description adds useful context about what the result contains (purpose, plain-language permissions, page, screenshot, opening instructions), though it omits any auth or rate-limit caveats.
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 with no filler. The most important information (what the tool returns and where the id comes from) comes first.
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 rich annotations, 100% schema coverage, and an output schema, the description supplies everything the agent needs to call correctly: id source, expected return content, and no misleading omissions. Language behavior is fully covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both id and language are fully documented in the schema. The description only echoes the id source and does not explain the language parameter's effect beyond what the schema already states, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Full details of one ... app by id') and scopes it to the Gallery. Naming find_apps and list_apps as the id sources distinguishes it from the list/search siblings without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to obtain the id from find_apps or list_apps, which is the key usage context. It does not spell out when not to use it (e.g. vs get_studio), but the routing guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What PriorStates Studio is (makes small apps by asking; a Gallery of free apps), the price, and the links for every platform: web, Android (Google Play and APK), iPhone/iPad, macOS/Windows/Linux, Microsoft Store.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language for the reply's app text and links: en, zh (Simplified Chinese), zh-hant (Traditional Chinese), es, pt. Default en (zh when the need is written in Chinese). |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| what | Yes | |
| price | Yes | |
| languages | No | |
| platforms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds context that responses include pricing and platform links. It does not add auth, rate-limit, or response-format details, but those are less critical for this info lookup.
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?
It is one efficient sentence, front-loaded with the returned information. The platform list is dense but earns its place by clarifying scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with an output schema and fully documented parameter, the description covers what an agent needs to know. The main missing piece is routing against sibling tools, reflected in the usage score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single optional language parameter is fully described in the schema. The description does not mention language behavior, so schema does the heavy lifting as expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (PriorStates Studio) and enumerates the facts it returns: what it is, price, and per-platform links. This distinguishes it from sibling app-inspection tools, though it lacks an explicit verb like 'get'.
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 implies the tool is for general Studio information and download links, but gives no explicit when-to-use guidance, no comparison to find_apps/get_app/list_apps, and no when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every free app in the PriorStates Studio Gallery, by group (money, side business, home, health, learning, groups, work). Optional group filter by id or name.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Group id (money, business, home, health, learn, groups, work) or its name. | |
| language | No | Language for the reply's app text and links: en, zh (Simplified Chinese), zh-hant (Traditional Chinese), es, pt. Default en (zh when the need is written in Chinese). |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| groups | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the genuinely useful constraint that the result set is limited to free apps and is organized by group, but says nothing about ordering, volume, or result limits beyond what the output schema presumably carries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the scope front-loaded and the filter condition second. The inline enumeration of group names is somewhat redundant with the schema enum and introduces the minor naming drift noted above.
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 an output schema and full annotation coverage, the description only needs to convey scope and filtering, which it does. The remaining gap is the relationship to sibling tools (find_apps/get_app), which the agent must 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 coverage is 100%, so baseline is 3. The description only restates the optional group filter already documented in the schema, and its parenthetical group list ('side business', 'learning') drifts slightly from the schema's canonical ids ('business', 'learn'), which could nudge an agent toward invalid values.
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 resource and scope: "Every free app in the PriorStates Studio Gallery," plus the grouping dimension. The "free" qualifier distinguishes it from broader listing/search siblings such as find_apps, though it never names those siblings directly.
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: 'list everything, optionally filtered by group.' There is no explicit statement of when to prefer this over find_apps or get_app, nor any exclusion such as 'use find_apps if you need to search by keyword.'
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.
find_appsget_appget_studiolist_appsFree no-signup group planner: dates, RSVPs, place votes, shared checklist and split costs.
Your household's calendar, tasks, messages and apps. Read, update, or build new apps with AI.
Split rent and utilities by room, settle up and generate roommate agreements. Free.
Build personal interactive apps with real URLs and persistent storage, using any AI.
Add one secure layer between your agents and this server.