appsmith-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target clearly distinct resources and actions (workspaces, applications, pages, queries, JS objects, widgets, datasources). A few overlaps exist: appsmith_list_applications vs appsmith_search_entities both find apps, and get_widget/update_widget/clone_widget vs get_page are adjacent, but descriptions clarify each tool's distinct purpose well.
Naming Consistency4/5
Tools largely follow the appsmith_verb_noun pattern consistently (list_, create_, update_, delete_, get_, clone_, execute_, export_). Minor deviations like appsmith_whoami (noun-style) and appsmith_api_request (generic verb) break the pattern slightly, but the overall convention is coherent and predictable.
Tool Count3/5
At 30 tools, this is on the heavy side for an MCP server, exceeding the typical 3-15 well-scoped range. However, Appsmith is a broad platform covering workspaces, apps, pages, queries, JS objects, widgets, and datasources, so each tool reasonably earns its place across the resource categories.
Completeness4/5
The surface covers CRUD across most resource types: workspaces (create/list), applications (create/list/clone/delete/export/publish), pages (create/get/list), queries (create/update/delete/execute), JS objects (create/update/delete), widgets (get/update/clone). Minor gaps include no delete_page or delete_datasource, and the generic appsmith_api_request fallback covers edge cases.
Average 3.6/5 across 30 of 30 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

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 disclosure. It does mention that page ids and the default page are returned, which is mildly useful. However, it doesn't describe the return format, whether pages are ordered, or whether this is read-only vs. potentially triggering any side effects. For a read operation with zero annotation coverage, more should be disclosed.
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?
One concise sentence that directly states the purpose and output. No wasted words or redundancy. Could arguably describe the output shape more, but as written it is efficient and front-loaded.
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?
The tool is simple (one parameter, no output schema, no nested objects). The description adequately conveys the basic purpose and what's returned (ids and default page). Given the low complexity, the description is somewhat adequate, but it lacks any guidance on return structure and doesn't reference sibling tools for contrast.
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 a single documented parameter (applicationId as a string). The description adds minimal value beyond the schema since it doesn't clarify the format of the app id or where it can be obtained. With full schema coverage, baseline 3 is appropriate, and there's no additional semantic depth added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists the pages of an application' with a clear verb+resource, which is reasonably specific. However, it doesn't distinguish from the sibling tool 'appsmith_get_page' (which fetches a single page) or clarify whether this returns all pages across the listed application scope. It could more explicitly contrast with the single-page retrieval tool.
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, nor any context about prerequisites (e.g., needing an applicationId obtained from list_applications first). No exclusions or alternative tool mentions. The agent must infer usage from the name alone.
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 of behavioral disclosure. It does not state whether creation requires specific roles/permissions, whether workspaces are enforced as unique by name, whether creation triggers side effects, or what happens if a workspace with the same name already exists.
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?
One sentence, zero waste. For a single-parameter creation tool, this level of brevity is appropriate, though it borders on under-specification rather than true 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?
A mutation tool with no annotations, no output schema, and no behavioral detail. Given the sibling create tools exist, the description should clarify what a workspace is, what prerequisites exist, and what response/return can be expected. The current one-liner is minimal but leaves the agent to guess about error handling and permissions.
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%, so the single 'name' parameter is already documented in the schema. The description doesn't add format constraints, naming conventions, or uniqueness expectations beyond what the schema provides, validating the baseline 3.
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 ('Creates a new Appsmith workspace') with a specific verb and resource. It distinguishes from sibling tools like list/create_application, though it could be slightly more specific about what a 'workspace' represents in Appsmith's hierarchy.
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 create a workspace vs. use sibling creation tools like appsmith_create_application. There's no mention of prerequisites (e.g., whether the user needs specific permissions), or context on when a workspace is needed vs. using an existing one.
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 disclosure. It's clear this is a read operation, but the description doesn't disclose details like whether it requires specific workspace permissions, whether the plugin field is a name or ID, or the ordering/pagination of results. For a read-only listing tool with zero annotation coverage, the behavioral transparency 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?
The description is a single concise sentence that conveys purpose and an extra detail (plugin inclusion) with zero wasted words. It's appropriately front-loaded with the verb+object structure.
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?
For a simple list tool with one parameter and full schema coverage, the description is mostly adequate. However, given the number of list-type siblings (applications, pages, queries, workspaces, plugins), a bit more context about what this returns beyond 'the plugin' and how workspace scoping works would improve completeness. No output schema exists, so the description could have offered slightly more on what fields the results contain.
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 parameter workspaceId is documented in the schema ('Workspace id.'). The description doesn't add meaning beyond the schema, but with only one fully-documented parameter, the baseline of 3 is appropriate since the schema already handles the documentation burden.
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 uses a specific verb+resource ('Lists datasources') and adds useful scope context ('in a workspace, with the plugin each one uses'). It clearly distinguishes from siblings by noting the plugin inclusion, which helps differentiate from generic list tools like appsmith_list_applications or appsmith_list_pages.
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. It doesn't mention that it requires a workspaceId context established via list_workspaces, nor does it explain what plugin information is returned or how this differs from get_datasource_structure. Sibling tools like appsmith_list_plugins and appsmith_get_datasource_structure exist but no differentiation is offered.
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 carries the full burden of behavioral disclosure. It states what's returned (objects and function names) and that includeBody adds full source, but doesn't disclose read-only vs side-effect behavior, whether it requires authentication, pagination behavior, or what happens if the application has no JS objects. For a read/list operation it's acceptable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that conveys the core purpose precisely. Zero wasted words or redundant phrasing. Every element adds information value.
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?
The tool has a simple purpose (list JS objects) and a 100% covered schema, so the description adequately covers the core function. However, it could benefit from noting that these are action collections and how listing function names is useful, and there's no mention of the output shape beyond 'function names.' For a simple read-only list tool it's sufficient but not thorough.
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%, so both parameters have descriptions in the schema. The tool description adds meaning to includeBody by noting it 'includes full JS source' (relating it to the 'function names' mentioned in the description), providing context beyond the bare schema description. This bridges the parameter to the overall purpose, meeting the baseline 3.
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 it lists JS objects (action collections) of an application and their function names. This uses a specific verb+resource (list + JS objects) and adds clarifying detail that it covers action collections and function names. It's clear, though it doesn't explicitly distinguish from sibling list tools like appsmith_list_queries beyond naming JS objects specifically.
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 vs alternatives. It doesn't explain when this is preferred over appsmith_list_queries, appsmith_search_entities, or other list tools. The scope is implied (lists JS objects for an application) but there's no when/when-not guidance or mention of standalone entities vs application-scoped.
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 full burden. 'Creates' clearly implies a mutating/write operation, which is somewhat transparent. However, it doesn't disclose whether the operation is idempotent, whether it side-effects other resources, whether it requires specific permissions/roles, or what happens on duplicate names. For a creation tool, this is basic disclosure but lacks depth.
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?
A single, efficient sentence that states the action and context with zero wasted words. Perfectly sized for the simplicity of the tool.
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?
For a simple create tool with 2 parameters and no output schema, the description is mostly adequate but could benefit from noting typical post-create next steps (e.g., then adding pages) or clarifying naming constraints. Since annotations are absent, more behavioral disclosure would strengthen completeness, but the tool's simplicity keeps the gap modest.
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 schema already documents both parameters clearly. The description adds minimal extra meaning beyond what the schema provides — it confirms 'inside a workspace' context but doesn't add format, constraints, or behavioral details about either parameter beyond schema definitions.
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 ('Creates') and resource ('an application') and scopes it to 'inside a workspace'. It distinguishes from siblings like appsmith_create_workspace, appsmith_create_page, etc. However, it doesn't differentiate from clones like appsmith_clone_application which also creates an application, and the purpose overlaps with appsmith_generate_crud_page.
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. There's no mention of when a user would create an application versus clone one, or prerequisites like needing a workspace (implied by required workspaceId but not stated as a prerequisite step). No exclusions or alternative tool references.
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 disclosure. It mentions the page starts with an 'empty root canvas' which is useful, but it doesn't disclose whether this is destructive, whether the operation requires specific permissions, what happens if the name conflicts with an existing page, or what the response contains. For a mutation tool, this is a notable 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?
A single, information-dense sentence that communicates the core purpose and the key behavioral detail (empty canvas) without any waste. Zero filler words.
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?
The tool is a simple 2-parameter create operation with no annotations and no output schema. For such a tool, the description covers the essential purpose and the starting state of the object created. However, it omits useful behavioral details like name conflict handling, permission requirements, and associated default page tasks. Adequate but not thorough.
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 both parameters (applicationId and name) are documented in the schema. The description adds the context that the page starts with an empty canvas, which is behavioral context rather than parameter detail. Baseline 3 is appropriate since the schema handles 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 states clearly that this tool creates a page in an application with a specific behavior ('empty root canvas the editor creates'). It uses a specific verb (creates) and resource (page), which distinguishes it from sibling tools like appsmith_create_application, appsmith_create_workspace, etc. It's clear although it doesn't explicitly differentiate beyond the shared 'create' prefix across several tools.
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 explains the resulting page state ('same empty root canvas the editor creates'), which gives useful context about when to use it. However, it doesn't explicitly say when to choose this over alternatives like appsmith_create_application or appsmith_generate_crud_page, and provides no guidance on prerequisites (e.g., needing an existing application).
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 carries the full burden of behavioral disclosure. It notes the mutation nature implicitly ('creates') and explains datasource-derived context, but doesn't mention whether queries are saved automatically, whether the query is immediately executable, dependencies on publishing, or how the operation affects the app state beyond creation.
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 filler. The first states the action and scope, the second adds necessary dependency context. Every word earns its place.
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?
For a creation tool with 4 fully-documented parameters and no output schema, the description is reasonably complete. The datasource-derived plugin/workspace note addresses the main implicit dependency. However, it lacks guidance on what a successful creation returns or what happens on failure, which is partially mitigated by no output schema being expected.
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%, so the structured fields already document all 4 parameters. The description adds minor value by noting that the plugin and workspace are taken from the datasource, which clarifies that datasourceId drives those dependencies. However, it doesn't elaborate on name naming conventions or body format beyond what the schema states.
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 uses a specific verb+resource ('Creates a query on a page against an existing datasource'), clearly distinguishing it from siblings like appsmith_update_query and appsmith_delete_query. It states the resource type (query) and its two anchoring entities (page, datasource), which differentiates it well.
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 clarifies that the plugin and workspace are derived from the datasource, which is useful context. However, it doesn't explicitly state when to use this vs appsmith_update_query or appsmith_execute_query, nor does it mention prerequisites like needing an existing page and datasource (though these are implied by parameter names).
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 bears the transparency burden. It discloses this is a search operation (read-like behavior) and the scope (applications and workspaces), but doesn't describe return format, ordering, pagination, or case-sensitivity of keyword matching. Adequate basic disclosure but thin on behavioral detail.
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, efficient sentence with zero wasted words. It names both the action and the resource scope clearly and concisely.
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?
For a simple two-parameter search tool with full schema coverage and no output schema, the description is reasonably complete for basic use. However, it could benefit from noting how results map to entity types, whether results return globally or per-workspace, and how it differs from the list tools. Adequate but slightly thin given the lack of annotations.
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 both parameters are documented in the schema (keyword as 'Search term', entities with its enum values). The description adds the default-behavior note that entities defaults to all, which the schema implies but doesn't state explicitly. Baseline 3 is appropriate since the schema handles parameter documentation well.
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 'Searches applications and workspaces by keyword' states a specific verb (searches) with specific resources (applications and workspaces), giving a clear purpose. It aligns with the entities parameter which allows restricting to APPLICATION/WORKSPACE. It doesn't explicitly distinguish from the sibling list_workspaces/list_applications tools, though the search-by-keyword nature is distinctive.
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 search tool versus the sibling listing tools (list_workspaces, list_applications). It doesn't explain that search is for finding entities by keyword while list tools enumerate all entities, nor does it mention any exclusions or alternatives.
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 must carry the disclosure burden. It does disclose the key behavioral trait that write queries will actually write to the real datasource, which is valuable. However, it doesn't mention auth/permission requirements, error behavior, or whether execution is synchronous, providing only partial transparency for a side-effect-capable 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?
Two concise sentences with zero waste. The sentence about real datasource/writes is highly valuable and front-loaded appropriately. Could arguably add a bit more but is efficient as written.
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?
For a side-effect-capable execution tool with no annotations and no output schema, the description does surface the most critical risk (writes to real datasource) but omits behavioral details like whether it returns rows, response format, or any success/failure signals. Given the criticality of this tool's side effects, more completeness would be warranted for a higher score.
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 both parameters are already well-documented in the schema (actionId provenance from appsmith_list_queries; viewMode purpose). The description adds nothing beyond the schema for parameters, so 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 it executes an existing query/API by action id and returns the result. The verb 'Executes' plus the resource 'existing query/API' is specific. It distinguishes from siblings like appsmith_create_query or appsmith_update_query, though it doesn't explicitly name read vs write alternatives.
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 notes 'This runs against the real datasource — a write query will write,' which gives important cautionary context about side effects. However, it does not explicitly state when to use this vs alternatives like appsmith_api_request, nor does it mention required prerequisites (e.g., running appsmith_list_queries first, though schema hints at this via actionId description).
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 full burden. It discloses the tool performs introspection and returns schema (tables, columns, keys), and implies caching via the 'refresh' parameter wording. However, it doesn't disclose side effects (e.g., whether refresh mutates the cache, auth requirements, permission levels needed, or rate limits). For a read-style introspection tool, basic transparency is there but behavioral detail is thin.
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 a single efficient sentence that conveys purpose and scope without waste. It's front-loaded with the key verb and resource. Slightly more context (return format, when to use refresh) could be added without bloat, but the current text is appropriately concise.
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?
With no annotations and no output schema, the description must cover behavior adequately. It states what the tool returns (schema: tables, columns, keys) but not the structure of that return, pagination behavior, or size expectations for large data sources. The caching nuance via 'refresh' is mentioned but not elaborated. For a moderate-complexity introspection tool, it's adequate but leaves gaps.
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 both parameters (datasourceId and refresh) are documented in the schema. The description adds the introspection framing (tables, columns, keys) that helps interpret the output but adds little to the 'refresh' boolean semantics beyond what the schema states. Baseline 3 is appropriate given full coverage and minimal extra description 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 (returns/introspects) and resource (datasource schema) with specific scope (tables, columns, keys). It distinguishes from siblings like appsmith_list_datasources (which lists datasources, not their schemas). However, it could more explicitly differentiate from related introspection tools like get_page or list_queries. Overall it's clear but doesn't strongly emphasize sibling differentiation.
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 the tool is for retrieving datasource schema, but provides no explicit when-to-use guidance or exclusions. The 'refresh' parameter hints at cache behavior, but the description doesn't state when the cached vs fresh path is appropriate. Sibling names suggest it fits into a schema-exploration workflow, but no alternatives are explicitly named.
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 for behavioral disclosure. This is a read/list operation but the description never explicitly states it's non-destructive or read-only, doesn't mention auth requirements, pagination, or what happens when no queries exist. The body inclusion behavior is implied but not detailed.
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?
Single sentence, zero waste. It gets straight to the point with the essential scope qualifier (non-JS actions) and return content (datasource and body) in an efficiently front-loaded structure.
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 simple list tool with full schema coverage of both parameters and no output schema requirement, the description covers the essential purpose and scope. It slightly under-delivers on not naming the sibling alternative explicitly and not disclosing read-only/non-destructive nature, but otherwise is adequate for this tool's complexity.
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 documents both parameters with 100% coverage: applicationId ('Application id') and includeBody ('Include each query's configuration body'). The description adds marginal value by mentioning 'body' is part of the return, but doesn't explain what the body field semantically represents beyond the schema. Baseline 3 applies given full schema coverage.
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 it lists non-JS actions (database queries and API calls) of an application, including datasource and body. This is specific with a verb+resource and distinguishes from sibling appsmith_list_js_objects which lists JS objects, though it doesn't explicitly name it.
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 usage context by clarifying it lists non-JS actions (excluding JS objects), which indirectly tells the agent when not to use it. However, it doesn't explicitly state when to prefer this over appsmith_list_js_objects or appsmith_list_datasources, or mention the includeBody parameter's role in deciding when to use it.
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 for behavioral disclosure. It does disclose the size trade-off of full=true ('can be very large'), which is useful operational context. However, it doesn't clarify whether this is a read-only operation, error handling, or what happens with invalid pageIds. Partial transparency but not comprehensive.
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?
Single sentence, front-loaded with the core purpose, and the key caveat about full=true is delivered immediately. Zero wasted words.
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?
For a 2-param, no-output-schema tool with no annotations, the description covers the main use and the size warning. However, no guidance on error cases (nonexistent pageId) or relationship to the widget outline structure could help the agent anticipate the response shape. Adequate but minimal for a retrieval tool.
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% and both parameters (full, pageId) have descriptions in the schema. The tool description adds meaningful context about the 'full' parameter (explains the trade-off of raw DSL being large vs compact outline), which exceeds the schema's terse 'Return the raw layout DSL instead of an outline.' This justifies the baseline 3.
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?
Clear verb+resource ('Returns a page'), and the description adds the compact-outline vs full-DSL distinction which distinguishes it from generic getters. However, it doesn't explicitly contrast against sibling appsmith_get_widget, though the intent (page vs widget) is implicit in the name.
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 tells when to use full=true vs default outline mode, which is useful usage guidance for a somewhat ambiguous parameter. But it doesn't explicitly state when to use this tool vs alternatives like appsmith_list_pages (enumerate all) or appsmith_get_widget (single widget), leaving some ambiguity.
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 behavioral disclosure burden. It states it's read-only (returns properties), but doesn't disclose return format, whether widgetName must be unique across pages, how errors surface for non-existent widgets, or whether it requires the page to be published vs draft state. For a read operation with no annotations, minimal risk, but even basic output behavior is undocumented.
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 sentences, zero waste. The first sentence states purpose and differentiation; the second provides concrete usage guidance. Efficient and front-loaded.
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?
For a simple 2-param read tool with 100% schema coverage, this is largely adequate. However, with no output schema and no annotations, the description could usefully note what a typical response looks like or confirm it's a safe non-mutating call. The 'without dumping the whole layout' note adds value over sibling get_page, but completeness for an unannotated tool could be stronger.
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 schema already documents both parameters fully. widgetName has a helpful example ('spoa') and explanation. The description adds the purpose of retrieving values 'before editing' but no additional param detail beyond the schema. Baseline 3 is appropriate since schema covers everything.
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?
Description uses specific verb+resource: 'Returns one widget's properties from a page'. Clearly distinguishes from get_page ('without dumping the whole layout') and related sibling tools like update_widget, clone_widget. States the exact scope of what it retrieves.
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?
Description implies usage context ('Use this to see current values before editing'), suggesting it pairs with update_widget. However, it doesn't explicitly state when NOT to use it (e.g., when get_page is more appropriate for whole layout inspection), nor name alternative tools explicitly. The before-editing hint is useful but not comprehensive.
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 full behavioral burden. It discloses the return type (app ids) and scope (optionally per workspace), but doesn't describe pagination, result limits, sorting, or whether the read operation requires authentication. The disclosure covers basics but leaves notable gaps.
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, zero wasted words. The first states the core function and optional filter, the second highlights the output's downstream usefulness. Efficiently structured and front-loaded.
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?
For a simple read-only list tool with 1 fully-documented parameter and no output schema, the description conveys the essential purpose and return-value usage. It's reasonably complete for the tool's complexity, though it could mention whether results include page count or metadata. Given low complexity, 3 is fair.
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 workspaceId parameter is already documented in the schema as 'Restrict to a single workspace id.' The description echoes this optional-filter intent ('optionally filtered to one workspace'), adding marginal value but not going 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Lists Appsmith applications') and clarifies the optional workspace filter, which differentiates it from siblings like list_workspaces and list_pages. However, it doesn't explicitly distinguish across all sibling list tools, though the resource type is clear.
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?
It implies usage via 'optionally filtered to one workspace' and notes the return value feeds other tools ('Returns app ids needed by the other tools'), which provides useful context. But it doesn't explicitly state when NOT to use this tool or name alternatives like appsmith_search_entities for broader search.
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 does disclose the key behavioral trait: it makes the app 'live for viewers,' implying a potentially impactful/irreversible action that affects end users. However, it doesn't mention whether authentication/ownership is required, whether there's a confirmation step, or any side effects beyond publishing.
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, focused sentence with zero filler. It directly states the action, the object, and the consequence. Nothing could be trimmed without losing meaning.
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?
This is a single-parameter, side-effect-heavy action with no annotations and no output schema. The description conveys the core purpose but could add context about what happens to the current live version, whether prior save is needed, or what the viewer-facing impact is beyond 'live.' For a mutating deploy action with no annotation coverage, there's room for more behavioral context.
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 a single parameter (applicationId) documented in the schema. The description doesn't add any parameter-specific meaning beyond what the schema provides ('Application id.'), so it meets the baseline but adds no extra value for the single parameter.
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 uses a specific verb ('Deploys') with a clear resource (edit-mode state of an application) and outcome ('making it live for viewers'). It clearly distinguishes from read tools and the sibling export_application (which exports vs. deploys). However, it doesn't explicitly name any alternative for comparison.
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 usage context ('Deploys the current edit-mode state') which suggests when it's relevant (when edit-mode state differs from published). It doesn't give explicit when-to-use/when-not-to-use guidance or name alternatives. The mention of 'edit-mode state' is useful but implicit guidance.
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 of behavioral disclosure. It implies a copy operation (clone) but doesn't state the resulting behavior - e.g., what ID the clone gets, whether it appears in the application list immediately, whether the clone overwrites anything, or if there are permission requirements. For a mutation tool with zero annotations, more behavioral detail would be valuable.
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 a single sentence plus a usage hint - appropriately concise with zero wasted words. It's front-loaded with the primary purpose and adds the use case in the second sentence. Could arguably expand slightly on behavioral details, but for what it includes, it's tight 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?
The tool is simple (1 param, no output schema, no nested objects), and the description covers the core purpose and a use case. However, it doesn't address what happens after cloning (returned ID?), whether there are naming conventions for the clone, or whether the clone can be distinguished from the original. For a mutation tool with no annotations, slightly more behavioral/return info would improve completeness.
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 parameter applicationId is fully documented in the schema. The description doesn't add anything beyond 'within its workspace' regarding the parameter. Baseline 3 is appropriate since the schema does the heavy lifting, and the description provides only marginal added context about the parameter's role.
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 the tool clones an application within its workspace - a clear verb+resource. It distinguishes from siblings like appsmith_export_application and appsmith_create_application by specifying 'within its workspace' (as opposed to export or creating a new one). The name 'appsmith_clone_application' is unambiguous and the description reinforces the purpose clearly.
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 description provides clear usage context: 'Useful as a backup before risky edits.' This tells the agent when to use this tool (before risky modifications). However, it doesn't explicitly state when NOT to use it or name an alternative (e.g., when you'd want an export instead of a clone), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a destructive operation gated behind an environment flag, which is valuable behavioral context. However, no annotations are provided, so the description carries full burden; it doesn't mention irreversibility consequences, impact on dependent entities (e.g., references in pages), or side effects. The gating disclosure is a genuine plus but doesn't fully cover the destructive-action 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?
Two concise sentences with zero wasted words. The description front-loads the core action and adds the critical environment-gating caveat efficiently.
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?
For a single-parameter destructive operation with full schema coverage and no output schema needed, the description is reasonably complete. However, for a destructive action with no annotations, it could add more about irreversibility and what happens to dependent references. The gating info is helpful but the destructive implications are under-explained.
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 coverage is 100% with a single parameter (actionId) already described in the schema. The description doesn't add detail about what format actionId takes, but with one fully-documented parameter there's little to compensate for. The tool name and schema together make the parameter meaning clear.
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 'Deletes a query or API action' with a clear verb (delete) and explicit resource targets (query or API action). It distinguishes from sibling tools like appsmith_delete_application, appsmith_delete_js_object, and appsmith_create_query/update_query, though it doesn't explicitly name them.
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 provides context that the tool is disabled unless APPSMITH_MCP_ALLOW_DESTRUCTIVE=true is set, which gives the agent important prerequisite knowledge. However, it doesn't explicitly state when to use this vs alternatives like appsmith_update_query (for modifying rather than removing) or mention any confirmation requirements.
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 behavioral disclosure burden. It implies a read-only listing operation through 'Lists', which is helpful, but doesn't describe output format, whether it returns both plugin ids and names, pagination behavior, or auth requirements. For a simple listing tool this is acceptable but lean.
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?
Single concise sentence, zero waste, front-loaded with the primary action first, then examples and return-value hint. Appropriate for a simple read-only listing tool.
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?
This is a simple listing tool with 1 optional parameter and no output schema. The description covers the core purpose well. However, for a tool that returns a list of plugins (presumably including structured data), clarification of what fields are returned and whether ids can be used for subsequent calls would improve completeness, since the description mentions 'ids' without elaborating their role.
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 coverage is 100% (workspaceId is documented in the schema). The description's mention of 'and their ids' clarifies the return value purpose, which helps the agent understand why return values matter (collecting ids for later use). With full schema coverage, baseline is 3, and the description adds a bit beyond baseline by indicating the purpose of getting ids.
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?
Clear verb+resource ('Lists available Appsmith plugins') with explicit examples (Postgres, REST API, MongoDB). It distinguishes from sibling tools by focusing specifically on plugins, which is distinct from list_applications, list_datasources, etc. However, it could more explicitly differentiate from list_datasources since plugins and datasources are related Appsmith concepts.
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 usage (listing plugins to obtain their ids), but doesn't explicitly state when to use this vs alternatives, nor when the workspaceId param would be helpful. No exclusions or when-not-to-use guidance given.
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. It usefully discloses the diffing-safety behavior (deleted functions are removed, not just added/updated), which is valuable behavioral context beyond the schema. However, it does not address permissions/auth requirements, error conditions, or side effects like appsmith_publish_application would, leaving some transparency gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense, front-loaded sentence that explains both action and the nuanced diff behavior with zero filler. Every clause earns its place, and it fits in roughly one breath of reading.
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?
Given the tool has no output schema and only three parameters (all documented in schema), the description sufficiently covers the important semantic nuance of diff-based updates. The main gap is absence of note about desired behavior on error cases or auth, but for a reasonably straightforward mutation with 100% schema coverage, the completeness is strong.
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 schema already documents all three parameters. The description adds the key semantic detail that 'body' must include the required 'export default { ... }' wrapper form, which complements the schema's 'Full new source' phrasing. This is baseline-plus but doesn't elaborate on all parameter interactions.
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 ('Replaces') and resource ('a JS object's source'), making the tool's core purpose evident. It distinguishes from a naive body-write by explaining the function-diffing behavior, which sets it apart from sibling update tools like appsmith_update_query or a plain delete/create pair.
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 explains the diffing mechanism and why it matters (would otherwise leave deleted functions behind), which implies when it's beneficial. However, it does not name explicit alternatives or when-not-to-use conditions, relying on the implied comparison to appsmith_create_js_object and appsmith_delete_js_object instead of stating exclusions directly.
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. It does disclose a critical safety behavior (destructive methods require an env var), which is genuinely valuable. However, it doesn't disclose what happens on error, whether responses are parsed, auth requirements, or rate limits. It also doesn't discuss the scope of 'any endpoint' - e.g., whether it can reach non-Appsmith endpoints or is limited to the Appsmith API. The destructive-method gate adds meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, then the critical constraint. Zero wasted words. Every sentence earns its place - the first defines what it does and when, the second discloses the destructive-method gate. Efficient and clear.
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 generic REST-call tool with no output schema and no annotations, the description sets expectations reasonably well. It covers purpose, when to use, and the key safety gate. Given that this is a deliberately raw/escape-hatch tool, describing the full universe of possible behaviors might be counterproductive, but it could mention error handling or response format. The description is adequate given the tool's intentionally generic nature.
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 all 4 parameters have descriptions in the schema (method, path, body, query). The description doesn't add parameter detail beyond the schema, but with full coverage the baseline is 3. The description adds nothing about formatting of body/query beyond what the schema states, so it doesn't elevate above 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 it 'Calls any Appsmith REST endpoint directly, for things the typed tools do not cover.' This clearly states the verb+resource (calls Appsmith REST endpoints) and positions it as a raw/escape-hatch alternative to typed tools. It distinguishes its purpose from siblings (which are typed tools covering specific endpoints), though it doesn't enumerate which specific endpoints it covers beyond the generic capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is for 'things the typed tools do not cover', giving clear context on when to use it vs alternatives. It also states the important behavioral rule: 'GET is always allowed; other methods require APPSMITH_MCP_ALLOW_DESTRUCTIVE=true.' This is explicit usage guidance including a precondition/constraint.
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 does explicitly flag 'Permanently deletes' and the destructive-action gate, which is crucial behavioral disclosure. However, it doesn't describe consequences beyond deletion (e.g., whether related pages/queries are also removed, irreversibility detail beyond 'permanently', or auth specifics). The destructive warning is the key trait and is present.
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 sentences, zero waste. Every word adds value—states the action, its permanence, and the operational requirement. Front-loaded with the core purpose.
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 destructive action with a single parameter and no output schema, the description is lean but sufficient. It discloses the critical safety gate and permanence. It could arguably mention what is lost (child pages/queries), but the destructive flag and clear verb deliver the essentials for agent decision-making.
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% (the single applicationId param is described as 'Application id to delete'). The description adds no extra meaning beyond what the schema provides, so baseline 3 applies. For a single self-evident parameter, this is adequate.
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?
Clearly states it permanently deletes an application—a specific verb+resource. It distinguishes from siblings like delete_query/delete_js_object, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the destructive-nature gating condition: 'Disabled unless APPSMITH_MCP_ALLOW_DESTRUCTIVE=true is set in the server env.' This tells the agent when the tool will fail, which is critical usage guidance. It also implies this is a dangerous action, setting the barrier for when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a subtle behavior — that exported functions are stored separately and the source alone produces an object with no callable functions — which is genuinely non-obvious and valuable behavioral insight not captured anywhere else. It doesn't mention auth/permission requirements or exact side effects of creation validation, but the key behavioral quirk is well disclosed.
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 a tight two-sentence structure with the behavioral caveat front-loaded. Every sentence earns its place — the first states the action and the second explains the parsed-exports behavior. Minor waste: the phrase 'Creates a JS object from its source' slightly restates the name, but combined with the second sentence it's efficient and focused.
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 creation tool with 100% schema coverage and no output schema, the description is complete for the main task. It explains the format requirement, the parsing behavior, and the naming convention. It doesn't discuss validation failures or permissions, but those aren't strictly required for invoking it correctly. The key quirk that would surprise an agent (functions being stored separately) is fully covered.
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%, so the schema already documents all four parameters (body, name, pageId, applicationId). The description adds value by specifying the required source form ('export default { ... }') and explaining that name is referenced in bindings, which slightly exceeds schema. With full schema coverage, baseline 3 is appropriate; the description genuinely enhances understanding of body and name beyond schema text.
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 verb (creates), resource (JS object from its source), and adds crucial distinguishing detail about how exported functions are parsed out of the body. It contrasts against siblings like appsmith_create_query and appsmith_create_page, and its companion appsmith_update_js_object. The behavioral insight that 'the source alone would produce an object with no callable functions' makes the purpose unambiguous.
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 description doesn't explicitly name alternatives or exclusions, but it does convey essential usage context: this tool creates a JS object, and the format requirement ('export default { ... }') plus the parsing behavior implies when to use it (creating JS objects) versus updating them. It lacks explicit when-not-to-use guidance or mention of appsmith_update_js_object as an alternative, but the context is reasonably clear.
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 disclosure. It explains what gets created (table, form, queries) but doesn't state side effects like whether it creates/overwrites queries, whether existing pages/widgets are affected, whether the generator requires authentication or particular datasource types, or what the return payload looks like. For a generator tool with no annotation coverage, this is a notable 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?
Two well-structured sentences that front-load the primary purpose ('Runs Appsmith's own page generator') and add the differentiator ('supported way... rather than being assembled by hand'). Every word earns its place, no fluff or repetition.
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?
Despite 100% schema coverage and no output schema, the description adequately explains what the tool produces (table, form, wired-up queries) and when to use it. However, it omits behavioral specifics like whether optional parameters (columns, searchColumn) have validation constraints, how the generator handles multi-query side effects, and the nature of the return value. For a generation tool with moderate complexity and zero annotations, additional behavioral context would improve completeness.
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 already documents all parameters well. The description adds context by explaining the broader purpose of build artifacts (table, form, queries) that maps to what the tool assembles, and implies the relationships between the required parameters. It augments the schema's basic field labels with behavioral context.
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 verb ('Runs Appsmith's own page generator'), the resource ('builds a page with a table, a form and wired-up queries from one datasource table'), and explicitly differentiates from alternatives ('layout comes from Appsmith rather than being assembled by hand'). This distinguishes it from sibling create_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states this is 'the supported way to create a complete, detailed screen' and contrasts it with hand-assembling layouts, giving clear guidance on when to use this versus the alternative create_page approach. It also implies prerequisites via the datasourceId sourced from appsmith_list_datasources.
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 of behavioral disclosure. It communicates that the tool is a read-only, non-destructive confirmation operation by describing it as returning user/instance info and framing it as a 'confirm' step. However, it doesn't detail the return format, what happens on auth failure, or what specific instance fields are returned.
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 sentences, zero waste. Each sentence earns its place: the first states the function, the second gives the usage directive. Extremely efficient and front-loaded with the core purpose.
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 zero-parameter, no-output-schema, read-only diagnostic tool, the description is appropriately complete. It explains what it returns and when to use it. A slightly richer description of what the 'instance info' contains could improve it, but the current level is sufficient for an agent to invoke and interpret this tool correctly.
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 the schema coverage is 100% (empty object, trivially complete). The description adds the purpose context of the call beyond what an empty schema conveys. With no parameters to document, there's little more parameter-semantics value to add, so the baseline 4 for the zero-param case applies.
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 the tool returns 'the authenticated Appsmith user and instance info,' which is specific with a clear verb ('returns') and resource (authenticated user info). It defines the scope well. It doesn't explicitly differentiate from siblings, but as a whoami-style tool it's self-evidently distinct from the list/create/update/delete tools in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to 'Use this first to confirm the MCP server can reach and log into the instance.' This is a clear when-to-use directive with a diagnostic purpose, serving as a connectivity/auth check before other operations. It's excellent guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses that deletion cascades to 'all its functions', that nothing rewrites dangling bindings (a key behavioral gotcha), and that the tool is gated behind APPSMITH_MCP_ALLOW_DESTRUCTIVE=true. This goes well beyond what structured fields would provide.
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 sentences, zero filler. Every sentence earns its place: the first conveys the destructive action and cascade, the second conveys the reference-checking caveat and the env-var gate. Highly efficient.
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 simple delete tool with one parameter, the description covers the action, the cascade behavior, the dangling-binding caveat, and the auth/env gate. No output schema exists, which is expected for a delete. Slightly more detail about what happens on success (returned result) would push this to a 5, but current coverage is strong.
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 description adds the note that collectionId corresponds to 'JS object id, from appsmith_list_js_objects', which mirrors what the schema description already says (schema coverage is 100%). The description contributes little extra beyond the schema's documentation — the schema instruction to source the id from list_js_objects is the primary guidance.
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?
Clear verb+resource ('Deletes a JS object and all its functions'). Distinguishes from siblings like appsmith_create_js_object and appsmith_update_js_object by the deletion action, and the scoping ('and all its functions') adds precision about scope of deletion.
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?
Gives clear when-to-use context — 'Check for references first' — and warns about the destructive nature. The guidance about checking references was likely derived from the description itself. It does not explicitly name alternative tools, but the reference-check warning provides sufficient usage context. Missing explicit exclusions about when NOT to use.
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 disclosure burden. It reveals the noteworthy behavioral trait that output is truncated when returned inline, and warns that exports are large. However, it doesn't disclose what the JSON structure contains, whether the export is a full app snapshot, or any failure/edge-case behavior.
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 sentences, both earning their place. Front-loaded with the primary action, then the key use-case distinction (outputPath recommended vs inline truncation). Zero filler; every word adds information.
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 tool with only 2 simple flat params, 100% schema coverage, and no output schema, this description is reasonably complete. It covers the main decision point (file vs inline), the truncation caveat, and the size concern. It could briefly note what the exported JSON contains, but this is a minor gap for a simple export 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 coverage is 100%, so both parameters (outputPath, applicationId) are documented in the schema. The description adds semantic weight by recommending outputPath and explaining why (exports are large, inline returns are truncated), which goes beyond what the schema states.
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 verb (Exports), resource (an application), and output format (as JSON). It distinguishes this from sibling tools like appsmith_list_applications or appsmith_clone_application by emphasizing the export-to-file behavior. The purpose is specific and unambiguous.
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 description provides clear guidance on when to use the outputPath (recommended because exports are large), giving practical usage context. It's clear on when to use each mode, though it doesn't explicitly name alternative sibling tools or exclusion conditions.
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 of behavioral disclosure. It states this is a read/list operation and that results include ids, but does not disclose pagination behavior, ordering, response shape, or whether this includes only owned vs. shared workspaces beyond 'can access.' For a zero-parameter list tool, the disclosure is adequate but lean.
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 with zero wasted words. It front-loads the verb and resource immediately and adds the key scoping detail. There is nothing extraneous or repetitive.
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?
With 0 parameters and no output schema, the description covers the core purpose well. It discloses that ids are returned, which is useful for downstream tool chaining (e.g., using workspace ids with appsmith_list_applications or appsmith_create_application). Could mention pagination or whether shared workspaces are included, but for a 0-param list tool, this is near-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 0 parameters, so there is nothing to document. Per the rubric, 0 params gives a baseline of 4. The description correctly notes that results include workspace ids, which hints at the useful field in the return value even without an output schema.
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 verb ('Lists'), the resource ('workspaces'), and the scope ('the authenticated user can access, with their ids'). It is distinct from sibling tools like appsmith_list_applications and appsmith_list_pages, which address different resources. The phrase 'can access' adds a permission scoping nuance.
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 description implies listing is scoped to authenticated user's accessible workspaces, providing context. However, it doesn't explicitly state when-not-to-use or name a sibling alternative (e.g., when to prefer appsmith_create_workspace or appsmith_whoami for the current user's context). The usage context is reasonably clear from the resource and scope framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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. It discloses several behavioral traits: copy lands below siblings, bindings carried over as-is with any referencing the original still pointing at it, and the response lists what was renamed for repair. This is meaningful behavioral context. Some gaps remain (it doesn't mention whether the source widget is name-matched case-sensitively or what happens on pageId mismatch), but the core behaviors are well-disclosed despite zero annotation support.
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?
Four sentences, all substantive with zero fluff. Front-loaded with the core operation, then the critical 'why use this' insight, then placement/binding caveats. Slightly dense for a single paragraph, but every sentence earns its place given the tool's conceptual subtlety around copying-based widget creation.
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?
Given this is a moderate-complexity mutation tool with no output schema and no annotations, the description is fairly complete: it covers purpose, the unique add-mechanism rationale, placement behavior, binding side-effects, and remediation guidance. Minor gaps include not specifying response structure details and not stating failure modes (e.g., duplicate newWidgetName behavior), but the essential operational knowledge an agent needs is present.
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%, so the schema fully documents all 4 parameters. The description adds value by clarifying the properties param (overrides as {name: value}, bindings auto-registered) beyond the schema, and explains the newWidgetName constraint ('must not already exist' is echoed from schema). Most heavy lifting is in schema, so baseline 3 is appropriate with modest added semantics on the properties override behavior.
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?
Clear specific verb (clone) + resource (widget) with detailed scope: copies widget and everything inside it, places it in the same page under a new name, applies property overrides. Strongly distinguishes from siblings like appsmith_get_widget, appsmith_update_widget, and appsmith_create_widget (which doesn't exist as a sibling, reinforcing that cloning is the add-mechanism).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains WHY cloning is the way to add a widget (Appsmith's widget defaults live in frontend, not API), giving the agent the critical 'when to use' decision context. Also clearly describes when-not: notes the copy lands below siblings and bindings get carried over, implying the source must be a valid existing widget. This uniquely positions the tool among all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral transparency burden. It discloses that it merges (partial update, only passed fields change, datasource preserved) and explicitly warns that renaming is not supported because it rewrites bindings. This is genuinely useful behavioral context beyond the schema. It doesn't mention idempotency, error behavior, or response format, but the merge semantics and rename limitation are strongly transparent.
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 sentences, zero wasted words. Each sentence earns its place: first establishes the purpose and merge semantics, second clarifies the rename limitation. Front-loaded with the core action and scoping. Excellent economy.
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 6-param update tool with 100% schema coverage and no output schema, the description covers the essential semantics: merge behavior, rename limitation, and scope. The REST-only restrictions are handled by the schema. Could briefly mention idempotency/response, but for a partial-update tool with strong schema support this is reasonably 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?
Schema coverage is 100%, so all 6 params are documented in the schema. The description adds meaningful value by clarifying the merge behavior ('Only the fields you pass are changed — the server merges the rest'), which changes how an agent should treat partial updates. The REST-only restrictions are already in the schema. Slight gap: no elaboration on how REST-only vs query params interact with the merge semantics, but overall adds value.
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?
Clear verb+resource ('Edits an existing query or API action') with an explicit merge semantics statement telling the agent that only passed fields change and the datasource/settings are preserved. It also proactively distinguishes from renaming behavior, which clarifies the tool's exact scope against update tools in the sibling list.
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?
States clearly what the tool does (edits existing query/API) and explicitly notes what it does NOT do (rename, which needs a refactor). This contextualizes when the tool is appropriate. However it doesn't name sibling alternatives (e.g., create_query, appsmith_execute_query) explicitly, though the distinction is reasonably implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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. It meaningfully discloses the side-effect behavior: automatic binding registration into dynamicBindingPathList, literal removal, dot-path support for nested config, and non-interference with other widgets. This is genuinely useful behavioral context beyond what the schema shows.
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?
Three sentences, all information-dense with no filler. Each sentence earns its place: the example illustrates usage, the second explains the binding auto-registration mechanism, and the third clarifies dot-path support and scope isolation. Efficiently front-loaded with the core purpose first.
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?
This is a mutation tool with no annotations and no output schema, so the description must cover behavior. It does well explaining the binding mechanics, dot-path support, and lack of side effects on other widgets. It doesn't cover error cases or whether it returns confirmation, but for an update-widget tool with simple parameters, the coverage is reasonably complete. Nested objects are handled by explaining the flexible properties structure.
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 coverage is 100%, so baseline is 3. The description adds value by elaborating on the 'properties' parameter semantics—explaining how values with {{ }} become bindings versus literals, and that property names may be dot paths for nested config. This goes beyond the schema's brief parameter descriptions.
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 states a specific verb ('Sets') with a resource ('properties on a widget') and includes a concrete example. It clearly distinguishes from siblings like appsmith_clone_widget, appsmith_get_widget, and other creation/deletion tools by focusing specifically on updating widget properties.
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 description explains binding registration behavior (when values contain {{ }} vs literals), which gives clear context on how the tool processes property values. It also states that 'Other widgets on the page are left untouched,' implying scope. However, it doesn't explicitly name alternatives or state when NOT to use this tool (e.g., when to use appsmith_update_query or update_js_object instead), though the widget-specific focus makes this fairly clear.
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:

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

Score Badge

Copy to your README.md:

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

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/Davidgraciano/appsmith-mcp'

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