FlowAPI MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is slight overlap between health_check and system_info (both check system status) and between get_invited_wallets and get_invited_wallets_by_token (similar but differentiated by token parameter). Overall, descriptions are clear enough to avoid major confusion.
Naming Consistency3/5
Tool names are inconsistent in prefix usage: some start with 'flowapi_' (e.g., flowapi_health_check), others do not (e.g., search_users). The pattern is mostly verb_noun but varies between 'search' and 'list' for similar operations. This mix reduces consistency.
Tool Count4/5
With 19 tools covering multiple domains (users, workers, arts, collections, wallets), the count is appropriate for the server's scope. It is slightly on the higher side but still well-scoped without feeling bloated.
Completeness3/5
The tool set provides full CRUD for external workers but lacks update for users and delete for arts and collections. Also, arts and art collections are limited to read-only operations. There are notable gaps that agents may need to work around.
Average 3.1/5 across 19 of 19 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states 'Update external worker configuration', which implies mutation, but fails to describe side effects (e.g., whether changes take effect immediately, require a restart, or are reversible), permission requirements, or any impact on existing workers. This is insufficient for an agent to assess risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two sentences) with no wasted words. However, its brevity comes at the cost of missing critical information. A concise description that omits important details is not a strength. It is minimally acceptable but not optimally structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters including a nested object, no output schema, and no annotations, the description is severely incomplete. It does not explain the return value, what happens on success or failure, validation rules, or any constraints. The agent would lack essential context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description does not add any additional meaning beyond the schema—it does not clarify the structure of the 'config' object, acceptable values for 'endpoint', or the effect of 'is_active'. Baseline 3 is appropriate since the schema already provides adequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update external worker configuration' with a specific verb and resource. The addition 'System-level operation' hints at administrative scope. While it distinguishes from siblings like create, get, delete, and list by the verb, it does not explicitly differentiate from them or explain what 'configuration' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_external_worker or get_external_worker. The phrase 'System-level operation' implies privileged access but does not explicitly state prerequisites, when not to use, or what conditions should be met before updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states 'Create' (mutation) but does not mention what happens on duplicate names, validation of endpoint, whether changes are reversible, or what response is returned. The agent remains unaware of side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loads the core action. However, it leans toward under-specification rather than conciseness; additional useful information could be added without becoming verbose. Still, it avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should at least indicate what is returned (e.g., created worker object). It also lacks context about system-level permissions or side effects. For a creation tool with 4 parameters including a nested object, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond the schema. It does not explain how 'config' or 'is_active' affect creation, nor the expected format of 'endpoint'. No additional value provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new external worker' which clearly identifies the action and resource. Adding 'System-level operation for worker management' slightly distinguishes it from sibling tools like list_external_workers or update_external_worker, though it could be more precise about what 'external worker' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_external_worker or delete_external_worker. The phrase 'System-level operation' hints at authorization context but does not direct the agent on prerequisites or exclusions. With multiple worker management siblings, explicit usage guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It states it's a 'system-level administrative operation' and 'delete' indicates destructive action, but does not disclose whether deletion is reversible, cascading effects (e.g., what happens to associated data), or confirmation/authorization requirements. This is insufficient behavioral info for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words. Front-loaded with the primary action. Every part contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and one parameter, the description should provide more context about irreversible effects, permission requirements, and typical use scenarios. The sparse description leaves an agent under-informed about critical operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter, so baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides ('External worker ID'). For a single-ID tool, this is acceptable but doesn't add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and the resource ('external worker'), and adds a contextual hint that it's a system-level operation. This distinguishes it from sibling tools like 'create_external_worker' or 'get_external_worker'. However, it could be more specific about whether this permanently removes the worker or merely marks it as inactive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'system-level administrative operation' which implies elevated privileges, but provides no explicit guidance on prerequisites (e.g., admin role required), when NOT to use this tool (e.g., if worker has active assignments), or alternatives. Given many sibling CRUD tools exist, this is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states authentication is required but says nothing about what specific permissions are needed, whether the operation is read-only or destructive, rate limits, pagination, or what happens if chain/token combo is invalid. The statement is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two sentences, the description is efficient and front-loaded with the key action. However, the second sentence about authentication could be integrated or expanded slightly for clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools like 'get_invited_wallets', a description of the difference is missing. The tool is moderately complex with two required parameters, no output schema, and no annotations; the description is too brief to cover what happens on success/failure or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (chain_id: 'Blockchain chain ID', token_id: 'Token ID'), so baseline is 3. The description does not add additional semantics beyond the schema, such as expected format (hex? decimal?), supported chains, or token standard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get invited wallet addresses for a specific chain and token', specifying the verb (get), resource (invited wallet addresses), and the scoping criteria (chain and token). This distinguishes it from the sibling 'get_invited_wallets' which likely does not filter by token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'System-level operation requiring authentication' but provides no guidance on when to use this versus alternatives like 'get_invited_wallets' (which may not filter by token) or other wallet-related tools. No exclusions or context-specific advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It only adds 'System-level operation,' which is a hint but does not disclose read-only status, rate limits, data volume, or what the recommendation algorithm considers. The agent remains uninformed about side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. The first sentence states the core purpose, and the second provides an important context (system-level operation). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description should at least hint at what the response contains (e.g., list of art IDs, titles, metadata). It does not. For a tool with one parameter and no annotations, this is a significant gap. The agent lacks information needed to interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the count parameter already has a description in the schema). The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate. The 'System-level' note does not relate to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recommended arts for discovery, which distinguishes it from siblings like list_arts (which likely lists all arts) and get_art (single art). The phrase 'System-level operation' adds context that it's not user-specific. However, it could be more precise about what 'recommended' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as list_arts or search_users. There is no mention of use cases, exclusions, or when not to use it. The description only states it's for discovery, but lacks differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosure. It only adds 'System-level operation for wallet management', which hints at privileged access but does not clarify auth requirements, side effects (e.g., read‑only?), or what happens when multiple identifiers are supplied. The absence of output schema further limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words. The first sentence clearly conveys verb+resource+identifiers. The second sentence ('System-level operation for wallet management') is marginally redundant but does not harm clarity. Could be trimmed for even higher conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters, no output schema, and no annotations, the description is insufficient. It does not explain what happens if no identifier is given, what the tool returns (e.g., wallet IDs, balances, metadata), or how it relates to sibling tools like `get_user` or `get_invited_wallets`. An agent lacks key context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each parameter has a description), so baseline is 3. The description groups them as 'various identifiers' but adds no further meaning—e.g., whether parameters are OR‑combined, if at least one is mandatory (though schema lists none as required), or how conflicts are resolved. Thus no extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'wallet information for a user', and clarifies it operates by 'various identifiers', which matches the input schema. It somewhat distinguishes from siblings like `get_user` (user info vs. wallets) and `get_invited_wallets` (wallets via invitation vs. direct user lookup), though it could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., `get_invited_wallets` or `get_user`). The description does not state prerequisites, when not to use it, or how the identifiers should be selected. An agent is left to infer usage solely from the parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only states 'List art collections with optional filters. System-level operation.' It does not reveal whether the operation is read-only, what pagination behavior is (beyond schema defaults), authentication needs, or the expected response structure. This is insufficient for safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences, 8 words). Each sentence earns its place: the first states purpose, the second adds an important scope qualifier. There is no redundancy. However, the extreme brevity could be seen as under-specification, but structurally it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and zero annotations, the description is too minimal. It omits crucial context such as what 'art collections' contain, how to interpret the output, whether the result is sorted, and what 'system-level' implies for access control. The agent lacks enough information to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions). The tool description adds no extra semantic value beyond 'optional filters' – it does not explain how filters interact or the meaning of 'parent_id'. Per the rubric, baseline is 3 when schema coverage is high, and no additional context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('art collections'), and mentions optional filters. It distinguishes itself from sibling tools like 'get_art_collection' (singular) and 'list_arts' (different resource). The phrase 'System-level operation' adds scope context. However, it could be more specific about what data is returned (e.g., list of IDs vs details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_art_collection' or 'list_arts'. The phrase 'System-level operation' hints at permission requirements but does not clarify use cases or exclusions. This is a significant gap given the many related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It mentions authentication requirement ('sys_key') which is useful, but it does not disclose other behaviors such as rate limits, pagination behavior beyond the parameters, whether results are sorted, or what happens if filters are invalid. The description is adequate but lacks depth for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, which is concise but lacks structure. It front-loads the purpose ('Get list of arts') but the authentication note at the end could be integrated or expanded. The sentence could be split to separate purpose from authentication context for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (all optional), no output schema, and no annotations, the description is incomplete. It does not clarify the format of the 'parameters' JSON string (e.g., expected keys, operators), nor does it describe the response structure. For a list endpoint that uses a flexible filter parameter, the description should provide usage examples or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% description coverage, meaning each parameter (limit, offset, parameters) is documented with defaults and constraints. The description adds no extra meaning beyond stating 'with optional parameters and filters'. Since schema coverage is high, baseline 3 is appropriate – the description does not improve understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get list of arts with optional parameters and filters', which specifies the verb 'Get' and the resource 'arts'. This clearly distinguishes it from sibling tools like 'get_art' which retrieves a single art piece, and 'list_art_collections' which lists collections. However, it does not explicitly differentiate from similar list tools (e.g., 'list_external_workers' but the resource itself is enough).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is 'Works with sys_key authentication', which implies the tool requires a specific authentication method, but it does not explain when to use this tool versus alternatives like 'search_users' or 'get_recommended_arts'. There is no guidance on typical use cases, expected data volumes, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. The description only states 'System-level operation for administrative purposes' which hints at scope but doesn't disclose whether the operation is read-only, destructive, rate-limited, or returns paginated results. For a search tool with 5 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the main purpose. However, the second sentence is somewhat generic and could be more informative. It earns its place but doesn't add much value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description provides minimal context. It doesn't explain the search algorithm, sort order, whether results are paginated, or what fields are returned. For a search tool of moderate complexity, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description in the input schema. The tool description adds no additional context beyond what's in the schema parameters. With full coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for users with optional filters' which pairs the verb 'search' with the resource 'users'. The 'System-level operation for administrative purposes' provides additional scope that helps distinguish it from user-facing search. However, it doesn't explicitly differentiate from sibling tools like get_user or get_user_wallets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_user (which retrieves a single user) or other search tools. There is no mention of prerequisites, permission levels, or situations where this tool would be preferred. The 'for administrative purposes' hint is vague and doesn't replace explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Create a new user' and 'System-level operation', but does not disclose behavioral traits like idempotency, required permissions, what happens if the user already exists, or whether the operation is reversible. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose. It is efficient but somewhat terse; every sentence earns its place, though more context could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no required fields, no output schema, and no annotations, the description is too sparse. It does not explain return values, side effects, or system behavior. The agent lacks context to confidently invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents the parameters. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new user') and the resource ('in the system'). It differentiates from sibling tools like search_users, get_user, and delete_user by focusing on creation. The phrase 'System-level operation for user management' adds context about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'System-level operation' which hints at administrative use, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., inviting users via other flows) or when not to use it. No prerequisites, side effects, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states it is a system-level operation for invite management, but does not disclose authentication needs, side effects, rate limits, or return characteristics beyond the fact that it is a read operation. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no fluff. The first sentence clearly states the primary purpose, and the second adds context ('System-level operation'). Every piece of text has a function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema), the description covers the core action adequately. However, it lacks details about the return format, pagination, or what 'recently updated' means for the 'only_updated' parameter. An agent would need to infer the response shape, which is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('chain_id' and 'only_updated'). The description adds the qualifier 'for a specific chain,' which aligns with the schema. However, no additional parameter meaning is provided beyond what the schema already offers, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves invited wallet addresses for a specific chain. It uses a specific verb-resource combination ('Get invited wallet addresses') and qualifies with 'for a specific chain' and 'System-level operation for invite management.' This differentiates it from sibling 'get_invited_wallets_by_token', though it does not explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'get_invited_wallets_by_token' or other user-level tools. The phrase 'System-level operation' hints at administrative context but provides no exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for behavioral disclosure. It only states the purpose and does not disclose any side effects, required permissions, response format, or error behaviors. For a health check tool, details like whether it returns a boolean or a detailed status object are missing, leaving the agent with insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences totaling 12 words. It is front-loaded with the primary purpose. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema, no annotations), the description is still incomplete. It does not explain what the response contains (e.g., health status, connectivity details) or how the agent should interpret the result. A health check tool typically benefits from mentioning return format or success criteria, which are absent here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% trivially. Per guidelines, 0 parameters sets a baseline of 4. The description does not add parameter-specific meaning, but none is needed since no inputs are required. No further elaboration on parameters is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check FlowAPI system health and connectivity. Verifies system is operational.' The verb 'check' and resource 'FlowAPI system health' are specific. It distinguishes from siblings like 'flowapi_system_info' by focusing on health/connectivity rather than general system info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., flowapi_system_info). There is no mention of prerequisite conditions, when not to use it, or typical use cases beyond the basic description. The agent must infer usage solely from the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates a read operation ('Get') and a system-level nature, but fails to mention key behaviors: what happens if the ID does not exist, whether it is idempotent, if any permissions are required, or what the response format contains. The description is insufficient for an agent to anticipate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences with no wasted words. Every word serves a purpose: establishing the action, resource, scope, and context. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description should at least clarify what 'details' are returned or behavior on missing IDs. It does not. Sibling tools like get_user likely have richer descriptions, making this one feel incomplete for an agent to gauge sufficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, which already describes 'worker_id' as 'External worker ID'. The description adds the phrase 'by ID', which reinforces that the parameter is an ID but does not add new meaning beyond the schema. With high coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get external worker details by ID', which is a specific verb-resource combination. It identifies the exact operation (get) and resource (external worker), with the scope defined by ID. This clearly distinguishes it from sibling tools like list_external_workers, create_external_worker, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The phrase 'System-level operation' hints at intended use but does not state scenarios, prerequisites, or exclusions. The sibling list_external_workers exists but the description does not contrast with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the operation is a 'list' (implying read-only) and 'system-level', but does not explicitly confirm it is non-destructive, describe side effects, or clarify authorization needs. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The main purpose is front-loaded, and the pagination detail is included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should convey what is returned (e.g., an array of workers, total count, pagination metadata). It does not. It also lacks details about ordering, filtering, or behavior when no workers exist. The tool's completeness for an agent is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both limit and offset are documented in the schema). The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List external workers' with the specific resource (external workers) and mentions pagination. This effectively distinguishes it from sibling tools like create_external_worker, get_external_worker, update_external_worker, and delete_external_worker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_external_worker for a single worker) or prerequisites (e.g., required permissions for a 'system-level operation'). No exclusions or special context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It discloses that this is a 'system-level operation,' hinting at restricted access or internal scope. However, it does not mention any mutation risks, rate limits, or potential error behavior (e.g., what happens if the collection ID does not exist). It adds some value over nothing but falls short of fully informing the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, using only 8 words, which is concise but slightly under-specified. The key actions are front-loaded. Every word is earned, but the brevity limits completeness. A touch more detail on the system-level nature would improve without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, no output schema, no nested objects), the description covers the essential purpose. However, without annotations like readOnlyHint or any elaboration on return values or error cases, the agent might be uncertain about the tool's safety or scope. Completeness is adequate for a straightforward get operation but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single 'collection_id' parameter has a description), so the baseline is 3. The tool description adds minimal extra meaning beyond the schema—only clarifying that the ID is for an art collection. No additional semantics, formats, or examples are provided, meeting but not exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('art collection details by ID') and adds a system-level context. It distinguishes itself from 'list_art_collections' (listing vs. single retrieval) and 'get_art' (collection vs. individual art). However, it lacks differentiation from general get tools like 'get_user' or 'get_external_worker', missing a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives minimal usage guidance beyond stating it is a 'system-level operation', which implies internal use. There is no mention of when to use this versus 'list_art_collections' or any alternatives, nor are there prerequisites or conditions explained. The guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It labels the operation as destructive and admin-only, but it fails to mention whether deletion is permanent, what cascading effects occur (e.g., deleting associated records), whether the action is reversible, or if there are any authorization checks beyond 'system-level.' This is insufficient for a high-risk operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of only two short sentences, each adding distinct value: the action and the required privilege level. No redundant phrases or excessive detail. It is optimally front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (1 required parameter, no output schema) and high schema coverage, the description is minimally adequate. However, because it is a destructive admin operation, missing details about return values, error handling, or consequences beyond deletion make it somewhat incomplete for a cautious agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'user_id' with the description 'User ID to delete.' The tool description repeats 'by user ID' but adds no new semantic meaning. At full schema coverage, a baseline of 3 is appropriate as the description does not enhance understanding of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a user by user ID and adds that it is a system-level administrative operation. This distinguishes it effectively from sibling tools like get_user, create_user, or search_users, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies through 'system-level administrative operation' that elevated privileges are required, but it does not explicitly state prerequisites, when to use versus alternatives, or when not to use this tool (e.g., soft-delete options, user must exist). No guidance on side effects or recovery is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description bears full responsibility for behavioral disclosure. It only states what is returned and does not mention side effects (none expected, but not confirmed), authentication requirements, rate limits, or whether it is safe to call frequently. This is a significant gap for a tool that could have access implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key action and resource. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no nested objects), the description provides the core information about what is returned. However, it omits behavioral context such as idempotency, authorization needs, or whether the tool is safe to call from any context. For a tool with no annotations, the description should cover these basics to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100%. The description adds no parameter-level detail because none is needed. Baseline 4 is appropriate as the description does not need to compensate for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'system information' and elaborates on what's included ('configuration and connectivity status'). This distinguishes it from the sibling 'flowapi_health_check', which likely returns only health status, not full configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus the closely related sibling 'flowapi_health_check'. The description does not mention use cases, prerequisites, or exclusion criteria, leaving the agent to infer context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations are provided, the description solely bears the burden of behavioral disclosure. It correctly implies a read-only, non-destructive operation, but does not mention any behavioral details such as input precedence (which identifier takes priority when multiple are given), error responses, or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, no redundancy, and front-loaded with the core purpose. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is somewhat underspecified. While the purpose and basic constraint are clear, the lack of return value or behavior details (e.g., what user info is returned, what happens for ambiguous matches) leaves gaps for an AI agent to potentially misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description adds value by explicitly stating the minimum contract ('at least one identifier'), which is not encoded in the schema structure (no required fields). This compensates for the schema's lack of a validation rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'user information', and specifies that it operates by 'various identifiers', distinguishing it from sibling tools like create_user or delete_user. However, it does not explicitly differentiate it from search_users, which might also return user info by criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a necessary constraint ('At least one identifier must be provided'), which guides usage by preventing invalid calls. However, it provides no guidance on when to use this tool versus alternatives like search_users, or when to prefer one identifier over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'system-level operation', which hints at no user-specific filtering, and 'Get' clearly indicates a read operation. However, it does not disclose return format, error handling, or access implications. For a simple read tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler. The key information (verb, resource, qualifier) is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description is reasonably complete. It specifies the input (ID) and the purpose (art details). It does not describe the exact return shape, but for a getter this is fairly self-evident. Sibling tools like list_arts further disambiguate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the only parameter (art_id) with description 'Art ID'. The description echoes 'by ID' without adding new semantic detail. Baseline 3 applies since the schema already documents the parameter fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get art details by ID', using a specific verb and resource. It unambiguously distinguishes from sibling tools like list_arts or get_art_collection by focusing on single-art retrieval via ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies this tool is for retrieving a specific art when the ID is known. However, it does not explicitly name alternatives or state when not to use it. The context signals show list_arts as a sibling, which provides circumstantial guidance, but explicit exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![flowapi-mcp-server MCP server](https://glama.ai/mcp/servers/maksdizzy/flowapi-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/maksdizzy/flowapi-mcp-server)

Score Badge

Copy to your README.md:

[![flowapi-mcp-server MCP server](https://glama.ai/mcp/servers/maksdizzy/flowapi-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/maksdizzy/flowapi-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maksdizzy/flowapi-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server