Sciple Platform MCP Server

Official

by sciple-idp

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Server Quality Checklist

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

Latest release: v0.10.0
Disambiguation4/5
Most tools are clearly separated by resource and action, and the athena_*/db_* prefixes help partition query tools. The main ambiguity comes from dual ticket paths (create_ticket vs create_project_ticket, get_ticket vs get_project_ticket, list_tickets vs list_project_tickets), but the descriptions are explicit about which to use.
Naming Consistency3/5
The dominant pattern is verb_noun (list_dashboards, create_environment, update_service), but several tools put the domain first (athena_run_query, db_query, athena_cancel) or use 'athena_history' without a verb. Add_panel/add_cell also deviate from the create_* convention, making the set readable but inconsistent.
Tool Count1/5
60 tools is an extreme count for a single MCP server and bundles many unrelated domains—dashboards, Athena, SQL, AWS resources, projects, tickets, runbooks, and services. Even if each tool is individually useful, the combined surface is too heavy for an agent to navigate efficiently.
Completeness3/5
Several domains have solid CRUD coverage, especially tickets, services, dashboards, and runbook cells, but there are notable gaps: no panel update, no runbook update/delete, no project update/delete, no environment group update/delete, and no API to discover datasource_id (needed by add_panel). There is also no user lookup tool, which would help resolve assignee_user_id.
Average 4.1/5 across 60 of 60 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on June 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
Annotations are absent, so the description bears the full burden of disclosure. It mentions the introspective action but does not state whether it is read-only, what the return structure looks like, or any potential side effects or limitations. The parenthetical only hints at scope without clarifying behavior.
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 brief and front-loaded with the primary action, followed by a compact argument list. For a tool with a single parameter, this is appropriately sized with no wasted words, though it could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to elaborate on return values. It states the purpose clearly enough for a simple introspection tool, but lacks any usage context, such as which connection types are supported or when to prefer this over sibling tools. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description's explanation of connection_id as 'The DB Console connection id' adds little beyond the parameter name itself. It does not provide format, source, or validation context, failing to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'introspect' and the resource 'connection', with a parenthetical listing the levels (databases / schemas / tables / columns). This makes the core purpose unambiguous and distinguishable from Athena-specific siblings by the explicit mention of 'DB Console connection', though it does not name any specific sibling.
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?
There is no guidance on when to use this tool versus alternatives like db_query, athena_list_tables, or athena_describe_table. No prerequisites, exclusions, or contextual cues are provided, leaving the agent to 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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the persist operation and scoping, but does not disclose behavior on duplicate names, whether it updates or creates, permissions required, or side effects. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise: a clear purpose sentence followed by a compact Args block. Every line adds relevant information, though the Args section could be more descriptive without much added length.
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?
While an output schema exists, the description lacks important operational details such as conflict/overwrite behavior, whether the tool creates or updates, and when to prefer it over sibling save tools. For a write operation with no annotations, this leaves the agent without enough context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides one-line explanations for each parameter, with 'The DB Console connection id this saved query belongs to' adding real context, but 'Short label' and 'The SQL text' are minimal and add little beyond the schema titles.
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 ('Persist'), a resource ('a SQL query'), and a scope ('under the caller's user, scoped to a connection'), making the core function clear. It does not explicitly differentiate from siblings like athena_save_query, though the mention of 'DB Console connection' hints at the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as athena_save_query or db_query. The description only states what it does and lists parameters, leaving the agent to infer the appropriate context from the tool name and sibling list.
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?
Annotations are absent, so the description bears the full burden. It only states 'Create an environment group' and lists parameters. It does not disclose side effects, persistence behavior, idempotency, authentication requirements, or what happens on failure. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear one-line purpose followed by a bulleted parameter list. Information is front-loaded with the action. No fluff or redundancy, though it lacks a high-level summary of what an environment group is.
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?
All parameters are explained, and an output schema exists. However, the description omits context like whether the group is immediately usable, how it relates to other resources (e.g., environments), or return value details. For a simple create operation, this is adequate but leaves room for more 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 coverage is 0%, so the description must compensate. It does so by explaining each parameter: 'name: Display name, e.g. Production accounts', 'slug: URL-safe id; generated from name if omitted', 'description: Optional description', 'display_order: Sort order in the UI', 'aws_account_id: Optional AWS account id to bind the group to'. This adds semantic meaning beyond the schema's bare titles and includes an example for name.
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 explicitly states 'Create an environment group' with a specific verb and resource. It is unambiguous and clearly distinct from the sibling list_environment_groups tool since no other mutation for environment groups exists.
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 does not mention prerequisites (e.g., needing an AWS account ID), order of operations, or scenarios where this tool is preferred. The description simply states the creation action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that deletion is irreversible, which is critical for a destructive operation. However, it does not describe any cascading effects, permissions required, or failure conditions, leaving some behavioral context undisclosed.
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 brief, front-loaded with the core action and the critical irreversibility warning. The Args block is slightly redundant with the schema, but it does not add meaningful bloat, so overall structure is 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?
For a one-parameter delete operation, the description covers the essential action and risk. However, with no annotations and no output schema details relied upon, it leaves open questions about dependencies, authorization, and what constitutes a valid service id, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args line says 'service_id: The service id to delete,' which adds almost nothing beyond the schema's 'Service Id' title and the tool's purpose. No format, source, or example is provided, so the parameter meaning remains shallow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete'), a clear resource ('a service from the catalog'), and the mechanism ('by id'). It is unambiguous and easily distinguished from sibling tools like create_service, update_service, and list_services.
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?
There is no guidance on when to use this tool vs alternatives, nor any mention of prerequisites or cases where deletion should be avoided. The warning 'This cannot be undone' implies caution, but it does not explicitly direct the agent about when to choose this tool.
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 only says 'list', which implies a read-only operation, but it does not mention pagination, sorting, authentication, rate limits, or any side effects. For a tool with no annotations, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the action and resource. It includes the key output fields without fluff, making it 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?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description is mostly complete. It lists the return fields, which is helpful, though it does not mention any filtering or additional behavior. The output schema likely covers the return format, so this is adequate.
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 input schema is empty. Per the rubric, a baseline of 4 applies since there are no parameters to document. The description does not add parameter semantics but none are needed.
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 and resource: 'List environment groups' and lists the fields returned (id, name, slug, aws account binding). It is specific enough to distinguish from sibling tools like list_environments, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus siblings such as list_environments or list_aws_accounts. The description only states what it does, leaving the agent to infer usage context.
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. It discloses that it persists a query under the caller's user and scopes to a workspace, which implies a write operation, but it does not mention potential side effects (e.g., overwriting existing queries, uniqueness constraints), permission requirements, or failure modes. This is minimal for a mutating 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 extremely concise: a single sentence describing the action followed by a compact argument list. Every word serves a purpose, and the core purpose is front-loaded. No redundancy or unnecessary detail.
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, and an output schema exists, so return values are covered. However, the description lacks context about uniqueness rules, whether saving overwrites existing queries, or any prerequisites. It also does not differentiate from the similar db_save_query sibling, leaving an agent to infer the difference. For a persistence operation, this is adequate but not thorough.
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 0%, and the description compensates by providing clear meanings for all three parameters: workspace_id, name, and sql. Each parameter is described with its purpose and relationship to the saved query, which is meaningful beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Persist a SQL query' with scoping to user and workspace. It's specific enough to distinguish from running a query, but it does not name any sibling tools, so it relies on the verb to differentiate (e.g., from athena_run_query).
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?
No explicit guidance on when to use this tool versus alternatives like athena_run_query or db_save_query. The usage is implied by the 'persist' action, but there is no explicit 'use for saving, not executing' or comparison with siblings. An agent would infer the purpose from context.
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 burden of behavioral disclosure. It does reveal a key behavior: 'Only provided fields change', which indicates partial update semantics. However, it does not mention side effects, authorization needs, whether null values clear fields, or reversibility, so coverage is only partial.
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 compact, front-loaded with the main purpose, and then organized into a clear Args list. Every sentence contributes information, and there is no redundant or filler content.
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 an output schema present, the return value does not need explanation. The description covers all six parameters and the partial-update behavior, which is enough for a basic call. However, it omits important operational context such as whether explicitly null fields are cleared, what happens to unmentioned fields, and whether certain combinations are invalid.
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 0%, so the description must compensate. It does so by giving each parameter a meaningful one-line explanation, e.g., 'Move to a different environment group' and 'Set/unset default.' This goes beyond bare schema property names, though it stays concise and could include more detail about null semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource, 'Update an environment', and immediately clarifies the partial-update semantics with 'Only provided fields change.' It does not explicitly differentiate from create_environment or delete_environment, but the name and resource make the core purpose clear.
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?
There is no guidance about when to use this tool versus create_environment, delete_environment, or list_environments. The phrase 'Only provided fields change' implies it is for modifying existing environments, but no prerequisites, exclusions, or alternative-routing conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it only states the destructive action. It does not disclose whether deletion is reversible, whether it cascades to related data, what error behaviors exist, or any permission requirements.
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 clear purpose statement followed by a minimal Args list. Every sentence is necessary and there is no filler or redundant information.
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 and an output schema exists, so return values need not be described. However, the description lacks behavioral and operational context for a destructive action, such as side effects, reversibility, or conditions for successful deletion.
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 schema provides no descriptions, but the description explains that runbook_id is the parent runbook id and cell_id is the cell to delete. This compensates for the zero schema coverage, though it could add more detail on ID formats or constraints.
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 and resource: 'Remove a cell from a runbook.' It clearly differentiates from sibling tools like add_cell, update_cell, and reorder_cells, leaving no ambiguity about what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as delete_panel or other delete operations. There are no conditions, prerequisites, or explicit exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action 'List' without disclosing behavior like read-only nature, authentication requirements, or any side effects. The lack of any behavioral detail beyond the verb is a significant gap for a tool with zero annotation coverage.
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, compact sentence with no superfluous words. It front-loads the verb and resource, and the parenthetical detail about connection types is concise and relevant. Perfectly sized for a zero-parameter tool.
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 list tool with an output schema, the description is sufficient to understand its core purpose. It doesn't explain return values, but the output schema covers that. It could mention typical usage (e.g., 'use this to discover available connections for db_query'), but that's not essential. Overall, complete enough for an agent to call it 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 input schema has zero parameters, so the baseline is 4 per rules. The description adds context about the connection types (RDS Postgres / MySQL), which is helpful but not parameter-specific since there are no parameters. No parameter documentation is needed.
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 a specific action (list), a resource (SQL Console connections), and the scope (in this tenant). It also specifies the connection types (RDS Postgres / MySQL), distinguishing it from sibling tools like db_query or db_describe_schema. No ambiguity.
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 related tools like db_query or db_list_saved, nor does it suggest prerequisites. For a simple list operation, usage might be implied, but the description doesn't help an agent decide when to invoke it over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but does not disclose side effects, reversibility, permissions, or what 'deprecated' means operationally; for a state-changing tool this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the action, usage condition, and parameter are each stated in minimal words. There is no filler or redundant content.
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 one-parameter state-change tool with an output schema, the description is minimally viable: it gives purpose, a usage trigger, and the required argument. However, because annotations are absent, it should also clarify whether deprecation is reversible and what side effects occur, leaving a noticeable completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'runbook_id: The runbook to deprecate,' which largely restates the parameter name and type. It does not clarify the ID format, how to obtain it, or any constraints beyond the schema's required marker.
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 opens with 'Mark a runbook as deprecated', a specific verb and resource, and the action is unique among siblings (deprecate vs promote/create/get). This makes the tool's purpose immediately identifiable without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage condition: 'Use when a procedure is no longer safe or relevant.' It does not name alternatives or exclusions, but for this domain the condition is clear enough to distinguish from promote_runbook and other runbook operations.
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, the description carries the burden of behavioral disclosure. It clearly indicates a read-only metadata inspection operation, but it does not attempt to disclose what happens for missing tables, permission requirements, or any other behavioral nuances. For a simple describe operation this is acceptable, though not deeply 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?
The description is compact and front-loaded with the main purpose, followed by a concise argument list. Every sentence contributes useful information without padding or repetition of the tool name.
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 three-string-parameter tool with an output schema available, the description provides enough context for correct invocation. It lacks explicit sibling routing and deeper caveats, but the combination of the short summary, parameter descriptions, and output schema makes it 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?
The input schema provides no descriptions (0% coverage), but the description compensates by explaining all three parameters in plain language. Saying database is 'The Glue database name' adds meaningful context beyond the schema's bare title 'Database.' The table parameter explanation is somewhat tautological, but overall the parameter semantics are sufficiently clarified.
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 operation: 'Show columns and partition keys for a single table.' It specifies a concrete verb and resource and implies a distinction from list-oriented Athena siblings like athena_list_tables. However, it does not explicitly name sibling tools or contrast 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 intended use is implied by the description: inspect table metadata/columns/partitions. There is no explicit guidance about when to prefer this tool over related tools such as athena_list_tables or db_describe_schema, and no mention of exclusions or prerequisites.
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 present, so the description carries the behavioral burden. 'Poll a single tick' reasonably implies a lightweight, non-destructive read that returns one status snapshot, which covers the safety profile. It does not disclose what the status values mean or how a caller should act on the response, though those are at least partially captured by the output 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 plus one parameter line, with the usage trigger front-loaded before the args. Zero wasted words; every sentence earns its place for a single-parameter poll 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 1-parameter poll tool with an output schema (which relieves the description of return-format duties), this is nearly complete. The gaps are the narrow trigger framing and the missing pointer to athena_get_results as the follow-up once status shows completion, both of which an agent must infer from sibling names.
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 0%, so the description must compensate; 'The Athena execution id' does add the basic semantic that this identifies a prior Athena query. It is, however, thin — it does not say where the ID comes from (the response of athena_run_query), which an agent would benefit from knowing to populate the parameter correctly.
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 verb 'poll' with 'a single tick' names the action and resource clearly — return one execution-status check for an Athena query. It reads as distinct from athena_run_query and athena_cancel, but it does not explicitly differentiate itself from athena_get_results, a close sibling that an agent could plausibly confuse it with.
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?
'Use when athena_run_query timed out' gives a concrete trigger condition tied to a named sibling. This is explicit and actionable. However, it frames a single narrow scenario and does not mention the broader legitimate use (polling status of any in-flight query) or the natural alternative/follow-up (athena_get_results once complete).
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 burden. It discloses genuinely useful behaviors: slug is auto-generated from name if omitted, is_default marks the tenant's default environment, and display_order controls UI sorting. However, it does not mention permissions, side effects, or what happens on duplicate names, which would be expected for a mutation with no annotation safety hints.
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 well-structured and efficient: a one-line summary followed by a compact Args list. Every parameter line earns its place and there is no filler or repetition.
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 that an output schema exists and all parameters are thoroughly documented, an agent has enough information to invoke the tool correctly. The main gaps are lack of usage guidance and incomplete side-effect disclosure, but these are partially covered by other dimensions and do not prevent successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, providing only titles and types. The description compensates fully by explaining all six parameters, including an example for name, auto-generation behavior for slug, parent-group semantics, and the meaning of display_order. This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Create an environment.' The Args also clarify that environment_group_id is only an optional parent, helping distinguish environments from environment groups. However, it does not explicitly contrast with sibling tools like update_environment or delete_environment, though the verb makes the core purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as create_environment_group or update_environment. An agent is left to infer that this is for creating a new environment based on the verb alone, with no conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'in-flight' and 'server-side' but does not describe side effects, whether cancellation is idempotent, what happens if the execution is already finished, or any permission requirements. This is a minimal behavioral disclosure for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear action sentence plus an Args block for the single parameter. Every sentence earns its place and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter cancellation tool with an output schema present, the description provides enough to select and invoke it. The main gaps are behavioral details like error handling and idempotency, but the operation and parameter are clearly specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description does clarify that execution_id is 'The Athena execution id', adding slight meaning over the schema title 'Execution Id'. It does not mention format, source, or relationship to other tools like athena_run_query, so the compensation is adequate but minimal.
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 ('Cancel') and target resource ('in-flight Athena execution'), and clarifies the server-side API call (StopQueryExecution). This clearly distinguishes it from sibling tools like athena_run_query and athena_get_execution_status.
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?
'Cancel an in-flight Athena execution' gives clear context for when this tool applies, and the 'in-flight' qualifier implies it is not for completed or failed queries. It does not explicitly name alternatives or state when not to use it, but the condition is clear enough for this unique operation.
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?
There are no annotations, so the description must carry the behavioral disclosure burden. It communicates the operation type ('list') but says nothing about whether results are paginated, whether the operation is read-only, or what permissions are required. This leaves notable behavioral gaps for a tool definition with no safety annotations.
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 compact and front-loaded with the main action. The parameter lines are minimal but useful, and there is no filler or redundant phrasing. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list operation with an output schema present, the description covers the essential invocation contract: what the tool does and what each parameter means. It does not address pagination or access details, but for this tool's complexity the description 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?
The schema provides no property descriptions (0% coverage), so the description must compensate. It gives a meaningful one-line semantic for both required parameters, specifying that workspace_id is an Athena workspace id and database is a Glue database name. This adds disambiguation beyond the bare property titles, though it does not specify value formats.
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 and resource: 'List tables in a Glue database.' This clearly distinguishes the tool from siblings such as athena_list_databases and athena_describe_table. An agent can tell what this tool does without further context.
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 natural use case—enumerate tables in a specified Glue database—but it gives no explicit when-to-use guidance or alternatives. Sibling tools like athena_describe_table or athena_list_databases are not referenced, so the agent must infer context from the tool name and wording.
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 available, the description must cover behavioral context. It does communicate that the operation mutates state by adding a comment, and it includes useful body constraints ('markdown supported, min 1 char'). However, it does not disclose permission requirements, potential side effects, or response behavior; the presence of an output schema partially mitigates the response gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose statement followed by a compact Args block. There is no filler, and every sentence adds useful information for invoking the tool.
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 two-parameter mutation with an output schema and no annotations, the description is largely complete. It defines both parameters, states constraints, and makes the behavior clear. It lacks usage guidance or alternative comparisons, but that gap is already accounted for in the usage_guidelines dimension.
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 0%, so the description must compensate. It does by explaining ticket_id as 'the internal ticket id' and body as markdown-supported with a minimum length. This adds meaningful semantics beyond the schema's bare string types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a comment to a ticket.' This is a specific verb+resource combination and is unambiguously distinct from sibling tools such as update_ticket, get_ticket, and link_tickets. The tool's purpose is immediately understandable without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives like update_ticket or link_tickets. There is no mention of prerequisites, exclusions, or scenarios where a different ticket-related tool should be preferred. Usage is only implied by the action name rather than explicitly described.
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, the description must carry the behavioral disclosure burden. It does disclose that the list is scoped to the caller ('caller's saved'), which is useful, but it does not describe return behavior, pagination, ordering, or whether the operation requires authentication. 'List' implies read-only, but no explicit safety statement is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear sentence for purpose plus a terse parameter note. No unnecessary filler; the key information is front-loaded.
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's low complexity—one optional parameter, no required arguments, and an output schema present—the description is largely complete. An agent can correctly invoke it with no arguments or with a connection_id. Minor gaps around parameter provenance and behavior with null values are acceptable but prevent a perfect 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 0%, so the description must compensate. It does add meaning by explaining that connection_id is optional and used to filter the list, but it does not clarify what format the id should take, where it comes from, or the exact filtering semantics.
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 and resource: 'List the caller's saved DB Console queries.' This clearly identifies what the tool does and distinguishes it from sibling tools like db_list_connections (connections) and athena_list_saved (Athena saved queries).
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 use case—listing saved DB Console queries—and mentions an optional filter, but it does not explicitly state when to choose this tool over alternatives such as athena_list_saved. There are no exclusion criteria or alternative routing guidance.
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 and it does communicate a read-only retrieval operation and what is returned. It does not mention error/not-found behavior or permissions, but for a simple read tool the core behavior is transparent enough.
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 compact, front-loads the purpose in the first sentence, and includes only the essential parameter explanation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter retrieval tool with an output schema, the description covers purpose and parameter meaning. It lacks usage guidance and failure semantics, but the operation is simple enough that an agent can correctly invoke it with the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema gives only the property name and type, so the description's Args section adds a minimal explanation ('The dashboard id to retrieve'). This is useful but essentially restates the schema's title rather than providing deep semantic detail.
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 and resource: 'Get a single dashboard's name, description, and panel list.' It clearly distinguishes this from the sibling list_dashboards tool by emphasizing 'single dashboard' and enumerating the return content.
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 such as list_dashboards or other get_* tools. It only repeats the required argument without explaining context or exclusions.
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, the description carries the burden of disclosing behavior. It signals a read-only operation via 'List' and mentions the output fields, but it does not address permissions, pagination, or scoping. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core purpose, and includes a useful usage example. The Args section is compact, though the 'project_id: The project id' line is somewhat redundant.
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 one-parameter list operation with an output schema available, the description covers the key intent and downstream usage. Extra details like permission requirements or pagination would be nice but are not essential for this endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for project_id (0% coverage), and the description only restates 'The project id.' This adds little meaning beyond the parameter name and type, and does not explain how to obtain the value or any constraints.
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 ('List') and resource ('members of a project'), and enumerates the returned fields (id, user id, role). This clearly distinguishes it from siblings like list_projects and list_project_tickets.
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 explicitly says to use it to find user ids to pass as assignee_user_id when creating or updating tickets. This gives clear decision-relevant context, though it does not state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal a key behavior: the entire execution order is replaced by supplying all cell ids. It does not mention potential side effects, permission requirements, or what happens if the runbook is in a particular state. Partial but useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear front-loaded purpose sentence followed by the crucial 'all cell ids' requirement and a compact Args section. No filler words are present, though 'Provide all cell ids in the desired sequence' slightly echoes the Args section without harming efficiency.
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?
The tool is simple (2 required params, no enums) and has an output schema, so the description does not need to explain return values. It covers purpose and parameter semantics well. It lacks explicit usage guidance and side-effect disclosure, but for a straightforward reordering operation, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly: runbook_id is explained as 'The runbook to reorder' and cell_ids is explained as 'All cell ids in the desired order' with an example. This adds significant meaning beyond the raw schema definition.
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 action and resource: 'Set the execution order of cells.' This clearly distinguishes it from sibling tools like add_cell, update_cell, and delete_cell, though it does not explicitly name alternatives. The purpose is unambiguous.
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 instruction 'Provide all cell ids in the desired sequence' implies the usage context: call this when you need to reorder all cells. However, it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or exclusions.
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, the description carries the burden of behavioral disclosure and does add real context: results are per-user, not workspace-wide, and limited to recent executions. It doesn't state ordering, whether running/failed executions appear, or other side effects, but as a history/read tool those omissions are minor.
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 front-loaded with the core purpose and contains a compact Args block; no filler or redundancy.
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 two-optional-parameter read tool with an output schema, purpose, scope, and parameter semantics are all covered. Only minor behavioral details like sort order or included execution states are left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described beyond the schema: workspace_id is explicitly 'optional... to filter the list,' and limit gets a range (1-500) and default (20) that the schema doesn't have. Since schema description coverage is 0%, this fully compensates.
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?
Names the resource (Athena executions) and scope (caller's recent history), so an agent can distinguish it from a broader execution list. It lacks an explicit verb like 'list' or 'retrieve,' but the meaning is unambiguous.
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 phrase 'for the caller (per-user history)' implies when to use it: to browse the current user's recent Athena executions. It doesn't explicitly compare against siblings such as athena_get_execution_status or athena_get_results, nor say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that 'key' becomes part of the ticket display id (e.g., 'PLAT-123'), and it notes defaults and optionality. However, it omits side effects such as uniqueness constraints on name/key, permission requirements, duplicate-handling behavior, or any post-creation effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well organized, with a one-line purpose followed by a structured argument list. Examples and constraints are placed inline where most useful. No filler or redundant information is present.
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 0% schema description coverage and no annotations, the description covers the parameter semantics thoroughly, and an output schema exists to cover return values. The main gap is contextual: it does not mention when to choose this tool over related creation tools or address potential duplicate/error scenarios. Overall it is sufficiently complete for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must do all the work. It fully compensates by documenting all five parameters: name length, key charset and length constraints, the key's role in ticket IDs, optional description, classification enum with default, and optional owner_user_id. Every parameter receives meaningful 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?
The description opens with the specific verb and resource: 'Create a new project.' This clearly distinguishes it from sibling tools like create_project_ticket, create_ticket, and create_environment. The name and description align tightly, leaving no ambiguity about what action is performed.
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 gives no guidance on when to use this tool versus alternatives such as create_project_ticket or create_ticket. There is no mention of expected context, prerequisites, or exclusions. 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.
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 burden. It adds useful behavior such as server-generated slug when omitted and defaults for default_branch and lifecycle, but it does not disclose side effects, idempotency, uniqueness constraints, or error 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?
The description leads with a one-line purpose followed by an efficient line-per-parameter list. There is no filler, and the structure is appropriate for a 15-parameter tool.
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 an output schema present, return-value details are unnecessary. The description covers all parameters, defaults, and formats, but it lacks high-level usage context and prerequisites such as where scm_provider_id comes from.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates thoroughly: every parameter has an example, allowed enum values, optionality, defaults, and a format example for links. This goes well beyond the bare 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?
States a specific verb and resource: 'Create a service in the catalog.' This clearly differentiates it from siblings like list_services, update_service, and delete_service, and from other create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus update_service or delete_service, and no prerequisites are mentioned. The intended usage is only implied by the word 'Create'.
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 behavioral disclosure burden. It does add useful context: directionality ('originates from' vs. 'other end') and the enumerated link types (blocks / relates_to / duplicates) with default. However, it does not disclose side effects, reversibility, idempotency, or behavior when a link already exists — meaningful 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?
A single purpose sentence followed by a compact Args block. Every line earns its place: purpose, three parameters with meaningful semantics, allowed values, and default. No filler, no repetition of schema defaults beyond what is useful.
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 core calling information is present — purpose, parameter semantics, allowed link types, and default — and an output schema exists so return-value details are covered elsewhere. However, with no annotations, the description omits behavioral edge cases (duplicate links, side effects, directionality semantics of 'blocks') and provides no usage differentiation from ticket siblings. Adequate but not 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 description coverage is 0%, so the description must compensate, and it largely does. It defines the directional role of each ticket parameter ('originates from' / 'other end') and spells out the allowed values for link_type with its default — information the schema lacks since no enums are declared. The explanations are terse but add real meaning beyond bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a relationship between two tickets.' This unambiguously identifies a link-creation operation, which is clearly distinct from sibling tools like create_ticket, update_ticket, and comment_on_ticket. No ambiguity about what the tool accomplishes.
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 does not explicitly state when to use this tool versus alternatives, nor does it name any exclusions. The intended usage is implied by the distinct purpose ('relationship between two tickets' vs. create/update/comment on a single ticket), but an agent gets no explicit routing guidance.
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, the description carries the full burden. It discloses synchronous execution, server-side access-profile gating of read-only vs read-write, and that an INSERT through a read-only profile errors at the platform. This adds meaningful behavioral 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?
The description is compact and well-structured: a one-sentence action, a short behavioral note, and an args list. No filler or redundant text.
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 two-parameter execution tool with an output schema present, the description includes the essential behavioral facts and parameter meanings. It lacks explicit differentiation against sibling query tools, but everything needed to call it correctly is present.
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 0%, but the Args block supplies meaningful descriptions for both parameters: connection_id is identified as the DB Console connection id, and sql is restricted to a single statement. This materially improves over bare type-only schema fields.
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 ('Run'), resource ('a SQL statement'), and context ('against a SQL Console connection'), and notes synchronous execution. This clearly distinguishes db_query from sibling tools like athena_run_query or db_describe_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. There is no mention of when to prefer db_query over athena_run_query or other query-related siblings, leaving the selection to inference.
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, the description carries the behavioral disclosure burden. It clearly discloses that deletion cascades to all panels and that the operation cannot be undone, which is strong for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient: two sentences state the action, scope, and irreversibility. The Args section is redundant with the schema but harmless and brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool, this is nearly complete: it names the target, the cascade behavior, and irreversibility. An explicit note about permissions or what happens to associated data would push it higher, but nothing critical is missing.
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 0%, so the description is the only semantic anchor for dashboard_id. It says 'The dashboard id to delete,' which adds the intended use even if it is not deeply detailed.
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?
States a specific verb and resource: 'Delete a dashboard and all its panels.' It also clarifies scope by explicitly including all panels, which distinguishes it from delete_panel and other dashboard mutations.
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?
Provides no guidance on when to use this tool versus alternatives such as delete_panel or update_dashboard. The irreversibility warning is important but is not usage 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?
With no annotations, the description carries the full burden and does disclose a crucial behavioral trait: 'This cannot be undone.' It does not, however, mention permissions, side effects on related data, or error behavior, so transparency is only partial.
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 compact: one sentence for the action, one sentence for irreversibility, and a clean Args list. All content is front-loaded and every sentence serves a purpose with no fluff.
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 operation with two string parameters and an existing output schema, the description covers the purpose, parameters, and destructive nature. It lacks explicit usage guidance, but the minimal complexity means the description is largely sufficient for an agent to invoke it 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 schema provides only property names and types with no descriptions (0% coverage). The description's Args section adds meaning by explaining that dashboard_id is the owning dashboard and panel_id is the target panel, which is essential for correct invocation.
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 'Delete a panel from a dashboard', which is a specific verb and resource. It distinguishes the tool from siblings like delete_dashboard and add_panel by focusing on panels rather than the dashboard itself.
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?
Usage is implied by the operation name and description: if you need to delete a panel, use this tool. However, there is no explicit mention of alternative tools (e.g., delete_dashboard for dashboards) or when not to use this tool, leaving the guidance implicit.
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 mentions what is returned ('name, status, and each cell's type/target/content preview') but does not explicitly state that the operation is read-only or disclose any side effects, performance characteristics, or auth requirements. This is acceptable for a simple get but not fully 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?
The description is extremely concise: two sentences plus a one-line args block. It conveys the primary purpose and parameter without redundancy, front-loading the core action 'Get a runbook with all its cells' before any secondary details.
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 that an output schema exists (per context signals), the description does not need to detail the return structure. It already summarizes key return fields. For a single-parameter, read-only tool, the description covers the essentials, though it omits mention of potential pagination or large response handling—likely unnecessary for a get-by-id operation.
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 input schema has one parameter (runbook_id) with only type and title, and schema description coverage is 0%. The description adds meaning by explaining 'The runbook id to fetch', which is sufficient for an agent to understand the parameter's purpose. It compensates for the schema's lack of detail.
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 ('Get') and resource ('runbook with all its cells'), clearly distinguishing it from siblings like list_runbooks (which lists multiple) and add_cell (which modifies). It uses precise language that leaves no ambiguity about the operation's scope.
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 (fetch a runbook by ID) but does not explicitly state when to use this tool versus alternatives like list_runbooks or get_dashboard. It lacks exclusions or conditions for selection, leaving the agent to infer from the parameter name.
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?
Annotations are absent, so the description carries the burden. It adds the uniqueness constraint (name must be unique within tenant) and length limit, which are behavioral constraints beyond the schema. However, it does not disclose permissions, failure behavior on duplicate names, or side effects 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?
The description is two sentences plus an args block, with the core purpose stated up front. No redundant filler.
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 2-parameter create tool with an output schema available, the description covers the parameters and the core action. It stops short of usage guidance and side-effect disclosure, but the output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by documenting both parameters: name has length and uniqueness constraints, and description is optional. This goes beyond the schema's bare type definitions.
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 starts with 'Create a new observability dashboard,' using a specific verb and resource. This clearly distinguishes it from sibling CRUD tools like get_dashboard, update_dashboard, and delete_dashboard.
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 does not explicitly state when to use this tool versus alternatives, but the 'Create' action and 'dashboard' resource imply it is for adding a new dashboard, while siblings handle retrieval/update/delete. No exclusions or prerequisites are provided.
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 must carry the full behavioral burden. It does disclose important interpretation behavior (project_id is not the key and number is the NNN), which helps avoid misuse. However, it does not state that the operation is read-only, any potential side effects, or error conditions. For a simple GET-like tool, the clarification of identifiers adds some value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by the mapping explanation and then parameter details. It includes a concrete example without extraneous text. Every sentence adds value, though it could be slightly more compact.
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's simplicity (two parameters, no nested objects) and the presence of an output schema, the description covers the main ambiguities: how to interpret the display id and which identifier to use. It does not mention not-found behavior or alternative tools, but these are not critical for a straightforward retrieval. Overall, it is complete enough for an agent to call it 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 schema provides only parameter names and types with 0% description coverage, so the description must explain the semantics. It does this well: project_id is explicitly 'NOT the project key', and number is 'the per-project ticket number (the NNN in KEY-NNN)'. The example (PLAT-42 -> project_id of "PLAT", number=42) further clarifies the mapping. This fully compensates for the sparse 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 it gets a project ticket by project_id and per-project sequence number, and explicitly explains the KEY-NNN mapping with an example. It distinguishes itself from the sibling get_ticket by specifying the two required identifiers (project_id and number), making its scope 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 includes a clear directive to use list_projects to obtain the project_id (not the key), which is essential usage guidance. It implies this tool is for retrieving a specific ticket when you know the number, but it does not explicitly contrast against list_project_tickets or get_ticket. This is still better than minimal 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?
With no annotations, the description carries the full burden. It indicates a read-only list operation and adds that it returns lifecycle status and cell count. However, it does not disclose potential pagination, ordering, performance limits, or error conditions, which are common for list operations. Minimal but not misleading.
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, well-formed sentence that conveys the exact purpose without any extra words. It is front-loaded and efficient, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters, the presence of an output schema, and the clear sibling get_runbook for individual retrieval, the description is complete for this simple list operation. It states the scope and the included fields, which is all an agent needs to call it 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, so the input schema is trivially complete. Per the baseline, a zero-parameter tool merits a 4; the description adds no parameter details, which is appropriate since there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'all runbooks in the tenant' and specifies the returned attributes (lifecycle status, cell count). It clearly distinguishes from siblings like get_runbook (single item) and create/deprecate operations.
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 that this tool is for retrieving all runbooks, which is clear from the name and wording, but it does not explicitly contrast with get_runbook or state when to prefer this over other runbook-related tools. No exclusions or alternative routing is 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, the description carries the full behavioral burden. It usefully discloses partial-update behavior and that None means "keep current" for content and target_config, but it does not mention overwrite side effects, permissions, or other mutation consequences.
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 plus a compact Args list. The key partial-update behavior is front-loaded, and every line adds useful information without repetition or filler.
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?
The description covers all parameters and the core update behavior, and the output schema makes return-value documentation unnecessary. However, target_type's "or None" is ambiguous about whether None clears the target or keeps it current, unlike the explicit notes for content and target_config.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args list is essential and fully compensates. Every parameter gets a meaningful explanation, including the allowed target_type values and the keep-current semantics for optional fields.
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 opens with a specific verb and resource: "Update cell content or execution target." This clearly distinguishes update_cell from siblings like add_cell, delete_cell, and reorder_cells, and the phrase "Only provided fields change" adds precise partial-update semantics.
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 on an existing cell but never explicitly states when to choose update_cell over add_cell, delete_cell, or reorder_cells. It provides no alternatives or exclusion conditions, leaving the agent to infer the intended context from the tool name.
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, the description carries the burden of warning about destructive behavior, and it explicitly states 'This cannot be undone.' This is a key safety disclosure, though it does not mention cascading effects or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the core operation and irreversible warning, followed by a compact parameter explanation. Every sentence earns its place with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive action with an output schema, the description provides the essential operation and irreversibility warning. It could add what gets deleted or preconditions, but the core context needed to invoke the tool is present.
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 0%, so the description must clarify the parameter. It defines env_id as 'The environment id to delete,' which adds meaningful purpose to the parameter beyond the bare schema field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair, 'Delete an environment by id', which unambiguously identifies the tool's operation. It also confirms the target resource (environment) among many delete_* siblings, so an agent can select it correctly.
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?
Usage is implied: use this when you want to delete an environment by its id. However, there is no explicit guidance on when not to use it, prerequisites, or alternatives such as update_environment or list_environments.
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, the description carries the behavioral burden. 'List' implies a read-only operation and the tenant scope is clear, but the description does not disclose pagination, ordering, limits, or authentication requirements. This is a modest gap for a simple list 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, front-loaded sentence that states the operation, scope, and key output fields with no filler words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema, the description provides the essential tenant scope and output fields. It is complete enough for correct invocation, although a brief note about pagination or read-only behavior would strengthen it.
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, so the schema already fully covers parameter semantics. The description adds no parameter-specific information, but none is needed; the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all projects in the tenant') and enumerates the return fields (id, key, name, classification). This clearly distinguishes it from sibling tools like list_dashboards, list_services, and get_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'all projects in the tenant' establishes clear context for a tenant-wide listing operation, but it does not explicitly state when not to use it or mention alternative tools. For a simple no-parameter list tool, the context is sufficient.
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 clearly indicates a state-changing operation by naming the lifecycle transitions, but with no annotations present it carries the full burden of behavioral disclosure. It does not mention potential side effects, irreversibility, permission requirements, or what happens if an invalid transition is attempted.
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 short, front-loaded with the core purpose, and every sentence adds value. The usage guidance and parameter explanation are clearly separated and easy to parse.
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 an output schema present and a single, well-explained parameter, the description covers the essential invocation details. It does not fully address edge cases like invalid current state or permissions, but it is reasonably complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides 'runbook_id' as a required string, and schema description coverage is 0%. The description adds a minimal but useful clarification that runbook_id is 'The runbook to promote,' helping an agent understand what value to pass.
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 specifies the tool's verb and resource: it advances a runbook through a lifecycle of draft -> reviewed -> standard. It differentiates itself from siblings like create_runbook, deprecate_runbook, and get_runbook by describing the promotion action rather than creation or deprecation.
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 when to call the tool: when authoring is finished and the runbook is ready for engineer review, or when an engineer has approved it as a Standard Operating Procedure. This gives concrete, actionable conditions for both lifecycle transitions.
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 takes on the burden of behavioral disclosure. It explains that description is optional and omitting it sets the value to null on the server, that name must be unique within the tenant, and that the operation is a full PUT. This gives the agent meaningful expectations beyond the schema, though it does not cover error handling or authorization.
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 front-loaded with the most important fact (full PUT) and then structured with a short explanatory paragraph and an Args list. It is reasonably concise and every section adds value, though the API/DashboardWrite sentence is slightly redundant with the opening.
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 three-parameter mutation tool with no annotations and an output schema present, the description covers the operation type, parameter constraints, null semantics, and uniqueness behavior. It is complete enough for correct invocation, though it omits details like conflict errors or whether the update is idempotent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by documenting every parameter: dashboard_id's role, name's length and uniqueness requirements, and description's null/omit behavior. Each parameter receives semantic detail that is absent from the raw schema, making this a model example of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Replace a dashboard's name and description (full PUT)' — this clearly identifies the operation and the fact that it is a full replacement rather than a partial patch. This distinguishes it from siblings like create_dashboard, delete_dashboard, and get_dashboard without ambiguity.
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 full PUT semantics and required name field imply this is for updating an existing dashboard, and the sibling names make the create/update/delete split reasonably clear. However, the description does not explicitly state when to prefer this over create_dashboard, nor does it provide exclusion criteria or mention that the dashboard must already exist.
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 available, the description carries the full burden of behavioral disclosure. It clearly states a read-only list operation scoped to the caller and mentions optional workspace filtering, both of which are meaningful behavioral traits. It does not detail ordering or pagination, but the output schema covers return expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a minimal Args block, with the main statement front-loaded. Every element earns its place, and the parameter explanation is concise without redundancy.
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 one optional parameter and an output schema, the description is nearly complete. It could note a dependency on athena_list_workspaces for valid workspace ids, but that is a minor omission given the straightforward nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the sole parameter. The Args section fully explains workspace_id as an optional Athena workspace id used to filter the list, adding semantic meaning beyond the bare schema type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clearly defined resource ('the caller's saved Athena queries'), which immediately distinguishes it from siblings like athena_run_query, athena_history, and db_list_saved. The scope ('caller's') and resource type ('saved') make 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when listing saved Athena queries) but does not explicitly name alternatives or exclusion conditions. An agent can infer differentiation from sibling names, but the text itself provides no direct guidance such as 'use athena_history for past executions'.
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 explains the conceptual meaning of a workspace and the role of the returned id. However, it does not state that the operation is read-only, what happens if no workspaces exist, or any pagination or permission details. For a simple list tool with an output schema, this is adequate but not fully 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?
Three short sentences, each earning its place: the first states the action, the second defines the resource, and the third explains how to use the result. It is front-loaded with the core purpose and contains no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool does, what a workspace represents, and how the returned id should be used by other Athena tools. With zero parameters and an output schema present, there are no significant gaps. The scope ('in this tenant') is also explicitly stated.
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, so the schema carries full coverage. The description adds no parameter-specific meaning because none exists. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the output's purpose rather than parameter details.
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 exact operation: 'List Athena workspaces in this tenant.' It further clarifies what a workspace is (an AWS account + region + Athena workgroup pinned as a query target), which distinguishes it from other list tools and gives the agent a precise mental model.
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 explicitly tells the agent how to use the returned value: 'The returned id is the value to pass as workspace_id on every other Athena tool.' This gives clear usage context and signals that this tool is the entry point for selecting a Athena workspace. It does not explicitly mention exclusions or when not to use it, but there are no direct alternatives for listing workspaces.
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 of behavioral disclosure. It explains the id-vs-key distinction and that the output is full details, but does not mention error behavior, permissions, or access requirements. For a read-only getter this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded: one sentence states the purpose, a second explains the parameter. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation, the description covers the essential acquisition path for the ID, and the output schema supplies the return shape. Minor caveats such as invalid-ID behavior or permissions are not covered, but they are not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare string field with no description, so the description's clarification that project_id is NOT the key and should be obtained via list_projects is essential. It directly prevents a likely misuse and adds meaning well beyond the 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 states a specific verb ('Get') and resource ('a single project's full details'), clearly distinguishing it from list_projects and other project-related tools. It is immediately obvious what this tool does.
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 gives a clear prerequisite: use list_projects first to find the project_id, and warns that the project key must not be used. It does not explicitly enumerate when not to use this tool, but the intended call path is well specified.
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. The verb 'List' conveys non-mutating behavior and the parenthetical documents the returned fields, but it does not mention potential caveats such as pagination, large result sets, or permission requirements. For a simple, parameterless list tool this is a moderate but acceptable transparency level.
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 one concise sentence that front-loads the action and scope, with the field list provided as a compact parenthetical. Every word earns its place and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with an output schema available, the description covers the operation, scope, and returned fields. An agent has enough information to select and invoke the tool correctly without missing essential context.
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?
There are zero parameters, so the baseline for this dimension is 4. The description adds value by clarifying what each environment entry includes (id, name, slug, group, default flag), which indirectly confirms that no input beyond the implicit tenant scope is needed.
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 and resource: 'List all environments in the tenant' and enumerates the returned fields (id, name, slug, group, default flag). This distinguishes it from sibling tools like list_environment_groups, which target a different resource type, and from create/update/delete_environment.
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 gives clear context by specifying the scope ('all environments in the tenant') and implies a read-only listing operation. It does not explicitly name alternatives or provide exclusion conditions, but the intent is unambiguous given the sibling tool set.
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 supplied, so the description carries the behavioral burden. It makes clear this is a read-only enumeration of project issue types and names the returned fields. It does not discuss pagination or permissions, but for a simple list operation the behavior is transparent enough.
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 short sentences: what it lists, why/when it's needed, and the parameter. The key information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, this is nearly complete: purpose, result fields, and required prerequisite are covered. It could be improved by pointing to list_projects or get_project as the source of a valid project_id, but that is not essential given the siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate. It only restates the schema's 'project_id' as 'The project id' without adding format, source, or constraints. The parameter name and schema title already convey almost all of this information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('issue types defined in a project') and enumerates the returned fields (id, name, parent_type_id). This distinguishes it from sibling list tools and create_project_ticket.
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?
It explicitly states that this must be run before create_project_ticket and why: the ticket needs a valid issue_type_id from this list. That is concrete, actionable usage guidance with no need for inference.
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 behavioral burden. It conveys that this is a read-only listing and names the display fields, but it does not disclose pagination, ordering, limits, or side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: one clear sentence stating the operation and output columns, followed by a single line of argument guidance. There is no unnecessary filler.
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 one-required-parameter tool with an output schema, the description provides the essential call information, including how to resolve the project_id. It could be more complete by explicitly distinguishing itself from list_tickets, but the low complexity keeps this minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The Args section clearly defines project_id as the project identifier and tells the agent how to find it via list_projects, fully covering the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List tickets in a project', and enumerates the displayed fields (id, status, priority, title, assignee). The 'in a project' scope clearly differentiates it from the generic list_tickets sibling.
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?
It provides a clear usage cue by telling the agent to use list_projects to find the project_id. It does not explicitly state when to prefer this tool over list_tickets or get_project_ticket, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description clearly implies a read-only listing operation and scopes results to the tenant catalog, but it does not disclose potential large-result behavior, pagination, ordering, or permission requirements. For a simple list this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly scoped sentence with no filler. The key action and resource are front-loaded, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema present, the description is fully sufficient. It states what is listed, the scope, and the expected fields. No additional context is needed for an agent to invoke it 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, which is the baseline 4 case. There is no input schema to clarify and no parameter ambiguity. The description's mention of returned fields adds useful context beyond the empty 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 uses a specific verb ('List') and a clear resource ('all services in the tenant catalog'), and even previews the returned fields (id, name, slug). This clearly distinguishes the tool from service mutators like create_service, update_service, and delete_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all services' gives clear context for when this tool is appropriate—retrieving the service catalog. It does not explicitly name alternatives or exclusions, but with zero parameters and a straightforward listing purpose, the intended usage is unambiguous among its 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?
With no annotations, the description carries the behavioral burden and does so well: it states partial-update semantics, clarifies that clear_owner/clear_tier remove assignments, that tags and links are replaced wholesale, and that environment changes are additive/removal. It could add permission expectations or failure behavior, but the mutation semantics are 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?
One crisp behavioral sentence followed by a dense, consistently formatted Args list. Every parameter line adds necessary information and the partial-update rule is front-loaded so the agent knows not to send nulls for unchanged fields.
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 19-parameter mutation with no annotations, the description supplies the essential selection criteria and parameter behavior; an output schema is present, so lack of return-value detail is acceptable. It is slightly incomplete only in not naming sibling tools or prerequisite conditions for updating an existing service.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description documents all 19 parameters with meaningful semantics: enumerated values for kind/lifecycle/tier, the meaning of boolean clear flags, and replace vs add/remove behavior for list fields. This goes far beyond what the bare schema provides.
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 opens with a specific verb and resource, 'Update a service', and adds the partial-update qualifier 'Only provided fields change.' This clearly distinguishes it from sibling create_service and delete_service operations by naming the resource and action.
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?
Usage context is implied: an existing service must be updated, since service_id is required and create/delete siblings exist. However, the description never explicitly says when to prefer this over create_service/delete_service or states exclusions, leaving the agent to infer selection criteria.
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, the description carries the full burden and adds useful behavioral context: cells execute in ascending order, target_type is null for markdown cells, and target_config examples show expected shapes. It does not discuss permissions, idempotency, or order-conflict handling, but the core behavior is transparent enough for safe invocation.
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 well structured: a one-sentence purpose followed by a compact Args list. Every parameter line adds value, and the JSON examples are informative rather than filler.
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?
The description covers required parameters, cell types, execution order, and target configuration formats, which is enough to call the tool correctly. Minor gaps remain around whether target_type is mandatory for shell/http cells and how conflicting order values are resolved, but these do not block use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters are fully explained despite 0% schema coverage: runbook_id, cell_type with allowed values, content, order semantics, target_type constraints, and target_config with concrete JSON examples. This completely compensates for the bare 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?
Opens with a specific verb+resource pair: 'Add a cell to a runbook,' which clearly states the action and object. The add semantics distinguish it from siblings like update_cell, delete_cell, and reorder_cells, even without naming them.
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?
Provides clear context for when the tool is used: adding a cell to a runbook with position/order semantics and execution-target options. It does not explicitly name alternatives or exclusions, but the purpose and parameter detail make the usage context unmistakable.
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 behavioral burden and handles it well: it discloses the page size (1000 rows), the pagination mechanism via next_token, and the required execution state (SUCCEEDED). It does not mention failure modes or error behavior, but the output schema covers return structure.
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 compact and front-loaded. The core behavior is stated in one clear sentence, and the parameter details are presented in a straightforward structured list without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides everything needed to invoke the tool correctly: the source execution, the page size, the optional token, and parameter explanations. The presence of an output schema covers return-value expectations, so no additional return-format details are required.
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 0%, but the description's Args section compensates by explaining execution_id as 'The Athena execution id' and, more importantly, clarifying next_token as an 'Optional page token returned by a previous call.' This adds meaningful pagination semantics beyond the schema's bare type/title/default.
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 ('Fetch'), a precise resource (result rows from an Athena execution), and a concrete behavioral detail ('next 1000-row page'). It clearly differentiates this from sibling tools like athena_run_query (starts a query) and athena_get_execution_status (checks status) by narrowing scope to results of a SUCCEEDED execution.
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 gives a clear precondition ('from a SUCCEEDED execution') and explains the pagination flow via next_token. It does not explicitly name alternatives like athena_get_execution_status for checking whether an execution succeeded, but the intended usage context is strongly implied and unambiguous.
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, the description carries the behavioral disclosure burden. It states the tool only lists databases visible to a workspace, implying a read-only, workspace-scoped operation with no mutation. The 'visible to a workspace' phrasing also signals permission-based scoping. The output schema handles expected return-shape details.
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 minimal and well-structured: a one-line purpose statement followed by a single parameter note. Every sentence earns its place, and the action is front-loaded without redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description covers what the tool does, the scoping, and where the required parameter comes from. The output schema supplies return-shape details, so nothing an agent needs to invoke this tool correctly is missing.
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 0%, so the description must compensate. It adds that workspace_id is the Athena workspace id and, more importantly, directs the caller to obtain it from athena_list_workspaces. This provenance hint is genuinely useful for invocation, though it stops short of describing value constraints or format.
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 opens with 'List Glue databases visible to a workspace,' which clearly specifies the verb (List), the resource (Glue databases), and the scope (visible to a workspace). It distinguishes itself from sibling Athena tools like athena_list_tables and athena_list_workspaces by naming databases rather than tables or workspaces.
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 gives clear context: this tool lists Glue databases for a workspace, and the workspace_id should come from athena_list_workspaces. It does not enumerate alternatives or explicit when-not conditions, but the purpose and the sourcing hint make the intended usage clear for this simple list operation.
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, the description carries the burden of behavioral transparency. It discloses that the runbook starts in draft status and that the tool returns the runbook ID – important side effects and outputs. It does not go into permissions or side effects beyond creation, but for a simple create operation it provides adequate behavioral insight.
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 structured with a clear lead sentence, return value note, and an Args block that efficiently documents each parameter. There is no fluff or repetition; every line earns its place. The format is easily scannable for an agent.
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?
The tool has an output schema, so the description need not detail return format beyond mentioning the runbook ID, which it does. It covers creation status and all parameters. It lacks explicit notes on error conditions (e.g., duplicate name) but these are not essential given the simplicity of the operation and the presence of structured schemas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly, explaining each parameter with examples ('Short, descriptive name', 'Markdown description of what this runbook does and when to use it', 'Optional list of tags for categorisation'). This adds meaningful semantic value beyond the basic types and defaults in the 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 ('Create'), the resource ('runbook'), and the status ('draft status'), which distinguishes it from sibling tools like get_runbook, promote_runbook, and deprecate_runbook. It immediately tells the agent what the tool does and what it returns.
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 usage: create a new runbook. It does not explicitly mention alternatives or exclusions, but its scope is unambiguous within the sibling set (all other runbook tools target different operations). The context is clear enough that an agent will know when to use it, though no proactive guidance about not using it for updates or promotions is provided.
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 clearly indicates a create operation (mutation) and scopes it to service-level. However, it does not disclose potential side effects (e.g., ownership, permissions required) or error conditions, relying on the obviousness of 'Create'. It adds some context about the scope but could say more about prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet complete. It leads with purpose and usage guidance, then lists all parameters in a clean Args block. Every sentence contributes information without fluff or redundancy, and the structure is easy to scan.
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 12 parameters and no annotations, the description covers all parameter semantics, usage, and scope. It is slightly lacking in that it doesn't mention that the service referenced by primary_service_id must exist, or clarify that a service ticket implies that ID is logically required even though schema marks it optional. Otherwise, it provides enough for correct invocation given an output schema exists to explain returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. Every parameter is explained with meaningful detail: allowed values for ticket_type and priority, formats for dates, and purpose of IDs like parent_ticket_id. This adds substantial value beyond the bare schema types and defaults.
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 explicitly states it creates a SERVICE-LEVEL ticket not bound to a project, using a specific verb and resource. It directly contrasts with create_project_ticket, distinguishing it from the main sibling. This makes the tool's purpose unmistakable.
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?
It gives explicit when-to-use guidance: 'Use this when the user explicitly wants a service-scoped ticket.' It also names the alternative create_project_ticket and explains why one would choose that instead (display id, custom fields). This is clear routing with no ambiguity.
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 burden of explaining the tool's behavior. It clearly states the tool lists accounts and enumerates the exact return fields, implying a read-only operation. It doesn't discuss pagination, permissions, or edge cases, but for a zero-parameter list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The main purpose is front-loaded, followed by a clear list of returned fields. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers a no-parameter, read-only list tool: what it lists, its scope, and what it returns. The output schema exists to define exact field types, so no return-value detail is missing.
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 an empty schema, so there is nothing to explain. The baseline is 4, and the description adds relevant context about what the returned `account_id` is used for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and resource ('AWS accounts connected to this tenant'), making the purpose immediately obvious. It is specific enough to be distinguished from sibling tools like list_services or list_ec2_instances.
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?
It provides clear context on when this tool is useful by explaining that the returned internal id is used as `account_id` in other cloud tools. It doesn't explicitly mention alternatives or exclusions, but no similar sibling exists, so a 4 is appropriate.
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 present, so the description carries the behavioral burden. It clearly indicates a read-only listing operation and specifies the returned fields. It does not mention pagination or ordering, but with zero parameters and an output schema present, this is a minor omission.
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 tightly worded sentence with no filler. Action, scope, and output fields are all front-loaded, making it immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, this description is complete: it states the resource type, the tenant scope, the 'all' filter, and the returned fields. Nothing an agent needs to invoke it correctly is missing.
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, so there is nothing for the description to document. Per the rubric, zero-parameter tools receive a baseline of 4, and the description correctly focuses on the output rather than inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List all') and identifies a precise resource ('observability dashboards in the tenant') while naming the returned fields (id, name, panel count). This clearly separates it from sibling tools like get_dashboard, create_dashboard, update_dashboard, and delete_dashboard.
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 'all' and 'in the tenant' phrasing establishes that this is the enumeration tool, and sibling names make the contrast with single-dashboard operations obvious. However, it does not explicitly state when not to use it or point to an alternative, though for a simple list-all tool the context is clear.
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 of behavioral disclosure. It does well by specifying the output format `[state] type id name (private_ip)`, the per-account grouping with running/stopped tally, and the effect of omitting account_id. It does not mention pagination or failure behavior, but for a read-only summary tool the disclosed behavior is substantial and sufficient.
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 compact and well-structured: purpose first, then output shape, then parameter semantics. Every sentence earns its place, and the Args section is cleanly separated from the behavioral overview. No redundant or filler content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter listing tool with an output schema present, the description covers the required inputs, default behavior, output formatting, and grouping semantics. The only minor omission is sorting/pagination detail, but the output schema and simple nature of the tool make the definition complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate for the bare input schema. It does: account_id is explained as an 'Internal account id from list_aws_accounts' with the default sweep behavior, and region is clarified with an example 'us-east-1'. This adds real meaning beyond property names and defaults.
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 opens with a specific verb and resource: 'Summarize EC2 instances' and clarifies the scope as 'for one account or across all of them.' It also distinguishes itself as a 'Convenience view over aws_ec2_instance' with a defined output shape, so an agent can separate it from broader cloud resource tools.
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 gives clear usage context: omit account_id to sweep all accounts, or provide it to filter to one account. It references list_aws_accounts as the source for valid account ids. However, it does not explicitly state when to prefer this tool over alternatives like query_cloud_resources or list_cloud_resource_types, so it misses the 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It states 'read-only', 'cached rows', and 'Large nested payloads are omitted from the summary; identity/scalar fields are shown as `key=value`'. This discloses that the tool returns a summary format, omitting heavy fields. It does not mention auth requirements or rate limits, but for a read-only query tool, this is reasonable. The description 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?
The description is well-structured: a concise summary, a prerequisite note, a behavioral note about output, and a clean Args list. Each sentence earns its place. The core purpose and read-only hint are front-loaded, and the parameter details are easy to scan. No fluff or repetition exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic query tool with an output schema (so return values are already described), this description is complete. It covers prerequisites, valid values, parameter semantics, pagination (page and page_size), and the output summary format. It even hints at how to handle region-specific behavior (e.g., 'global' for S3). Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document parameters. It does exactly that with an Args list: account_id is tied to list_aws_accounts, service to list_cloud_resource_types, resource_type has examples ('aws_ec2_instance', 'aws_rds_db_instance'), region includes a special 'global' value for S3, and page/page_size have defaults and ranges. This adds substantial meaning beyond the bare 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 opens with 'Query cached rows from any synced AWS resource table (read-only)', which clearly states the verb (query), resource (cached rows from any synced AWS resource table), and the read-only nature. It also calls itself a 'Generic accessor over every supported service', distinguishing it from specific tools like list_ec2_instances in the sibling list. This leaves no ambiguity about what the tool does.
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 instructs to 'Call `list_cloud_resource_types` first to find valid `resource_type` values', providing a clear prerequisite and usage context. It also states it is a generic accessor over every supported service, which implies it is the tool to use when querying any resource type rather than a specific one. However, it does not explicitly contrast it with sibling tools like list_ec2_instances or mention when not to use it, so it lacks explicit exclusions.
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, the description carries the behavioral burden and does so meaningfully: it discloses partial-update/PATCH behavior, that tags replace the full list, that ticket_id is the internal ID, and null semantics for optional fields. It does not mention permissions or side effects, but the disclosed mutation semantics are substantial.
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 front-loaded with the core semantics and common use cases, then follows a consistent, compact Args list. It is longer than average but every line earns its place given 11 parameters and zero schema descriptions to rely on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, output schema, and absent annotations, the description is essentially complete: it explains what the tool does, when to use it, PATCH behavior, field formats, replacement semantics, and ID pitfalls. The only minor blemish is the ambiguous 'pass empty string to unassign? Use null' note, which does not undermine overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does: every parameter is listed with added meaning — valid status/priority/severity values, ISO date format, title length limit, tags replacement behavior, and the internal vs display ID distinction. A few entries are low-value ('New description'), but the overall coverage is excellent.
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 opens with a specific verb and resource: 'Update a service-level ticket', and immediately clarifies PATCH semantics and common use cases (status transitions, reassignment, priority bumps). This clearly distinguishes it from sibling creation, commenting, and linking tools.
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?
It explicitly states when to use the tool: status transitions, reassignment, priority bumps, etc. It does not explicitly mention alternatives or exclusions, but the use cases and PATCH semantics are enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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, and it delivers: polling until SUCCEEDED/FAILED/CANCELLED, return payload contents, structured error codes, and the BYTES_CAP_EXCEEDED auto-cancel path. This gives the agent a strong model of side effects and error 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?
The description is dense but well organized: a summary paragraph, an error-behavior paragraph, and an Args list. Every sentence adds useful information, and the most important behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a polling query tool, the description covers invocation, parameter behavior, timeout handling, resumption path, success output, and failure modes. An output schema exists for the return value, so the description need not enumerate every response field, making this complete for selection and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters, and it does: workspace_id, sql with a single-statement constraint, and max_wait_seconds with its default and timeout semantics. This goes well beyond the bare 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 opens with a specific verb and resource: 'Run a SQL query against an Athena workspace' and clearly states the polling behavior and returned fields. It is easily distinguished from sibling tools like athena_get_results and athena_get_execution_status.
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 that the query must be a single SQL statement and that multi-statement queries are rejected by the parser gate. It also tells the caller that if `max_wait_seconds` elapses they can resume with `athena_get_execution_status`, which provides useful routing guidance, though it stops short of explicitly contrasting with all sibling alternatives.
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 the return value, the auto-increment behavior, and prerequisites. It does not mention error behavior, idempotency, or any side effects beyond creation, but given the detail level and the fact that it covers the key behavioral aspects, it is strong though not exhaustive.
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 efficiently structured: a one-sentence purpose, a justification sentence, prerequisites, and a bulleted Args list. It is dense with essential information, avoiding fluff. The Args list is necessary given the schema's lack of descriptions, so every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 13 parameters, the description covers all necessary invocation details: prerequisites, parameter semantics, allowed values, and cross-references to sibling tools. It also provides the output format. The presence of an output schema (not shown) may cover return fields, so the description does not need to repeat that. For the complexity involved, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides an Args section that explains every parameter, including allowed values (priority, severity), formats (dates), and cross-references (custom_fields uses list_project_issue_types). It even gives an example for custom_fields. This adds immense value beyond the sparse 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?
Description states a specific verb (create), resource (ticket within a project), and gives the output format (display id like 'KEY-NNN'). It clearly distinguishes from sibling tools like create_ticket (global) and list_project_tickets by specifying the project-scoped nature of the operation.
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 calls this 'the recommended path for most ticket creation' and explains why (auto-increment per-project number, human-friendly display id). It lists prerequisites (project_id from list_projects, issue_type_id from list_project_issue_types) and references the specific sibling tools needed to obtain them, leaving no ambiguity about when or how to use it.
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?
There are no annotations, so the description carries the disclosure burden. It clearly signals a read operation via 'Get' and flags a crucial behavioral trap: ticket_id must be the internal ID, not the display KEY-NNN. It does not spell out permissions or error behavior, but for a single-resource getter with an output schema this is adequate.
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 compact sections: a one-sentence purpose followed by a focused note on the single parameter. Every line adds information, and the most important constraint—internal ID vs display ID—is called out immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a one-parameter getter with an output schema present, so no return-format description is needed. The description covers the operation, the payload, and the ID source, making it complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, making the Args note essential. It defines ticket_id as the internal ID, explicitly excludes the display ID format, and names the lookup tools that produce it. This fully compensates for the bare 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?
Opens with a specific verb and resource: 'Get a single ticket's full details + activity counts.' It also distinguishes the by-internal-ID lookup from get_project_ticket, so the agent can tell it apart from the sibling ticket tools.
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?
Provides explicit routing: use list_tickets/list_project_tickets first to obtain the internal ID, or use get_project_ticket when the project key + number are available. This tells an agent when this tool is appropriate versus an alternative with no inference required.
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, the description itself carries the burden. It discloses that this is a read-oriented listing operation over currently synced types, and that it returns row counts, while also constraining inputs to an internal account_id from list_aws_accounts. It does not mention permissions, rate limits, or empty-result behavior, but no destructive or unexpected behavior is implied.
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 purpose and usage guidance are front-loaded, and the Args section is compact. The long service enum is necessary because the schema lacks an enum, and every line adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters, an output schema, and no annotations, the description covers what the tool returns, how to obtain inputs, and how it relates to query_cloud_resources. No essential call-time knowledge appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It defines account_id as the internal id from list_aws_accounts and enumerates the 19 accepted values for service, which the schema itself omits. This fully compensates for the lack of schema descriptions and enum constraints.
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?
States the action ('List') and a specific resource scope ('resource types synced for one AWS service in an account'). It also names query_cloud_resources as the follow-up consumer, which distinguishes this discovery tool from the query tool.
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 says to use it to discover valid resource_type values for query_cloud_resources and the row counts for each value. This gives the agent a clear decision rule and points to the related sibling instead of leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and handles it well. It discloses AND-composition semantics, optionality, default limit, the meaning of include_affected, and full-text search behavior. It also communicates the maximum limit range, giving the agent a clear model of what happens on execution.
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 well-structured and front-loads the core purpose. The Args block is compact but information-dense, and every line earns its place given the 10-parameter surface. There is no fluff or repetition beyond the brief restatement that filters are optional, which is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with 10 optional parameters and no annotations. It covers composition, defaults, per-parameter semantics, and the one conditional behavior (include_affected). Since an output schema exists, the absence of return-value detail is not a gap. Nothing essential is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by documenting every parameter in the Args section. It explains what each filter does, which statuses/priorities/types are accepted, and the special behavior of include_affected. This adds substantial meaning beyond the bare schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'List tickets across the tenant with optional filters.' This distinguishes it from related siblings like get_ticket and list_project_tickets by specifying the tenant-wide scope. The purpose is immediately identifiable without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives solid usage context: filters compose with AND, all are optional, and behavior with no filters is described explicitly. It does not explicitly name alternative tools or state when not to use this tool, but the tenant-wide framing and filter flexibility provide clear enough guidance for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses important behaviors such as the panel binding to the dashboard's default data source and possibly rendering empty without datasource_id, which log options are ignored for certain panel types, and default behavior for log_limit and log_wrap_message. This is substantive transparency.
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 long but well-structured: a nested shape list front-loads the decision logic, followed by a compact args reference. The overlap between shapes and args is justified given 24 parameters, and every section carries real decision-making value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 24-parameter tool with no annotations and no schema-level descriptions, this description covers the essential context: required parameters, mutually exclusive shapes, defaults, ignored parameters, and the datasource_id requirement. The presence of an output schema means return-value details are already structured, so no additional description is needed there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate — and it does comprehensively. Each parameter is explained with usage context, examples, and shape associations, such as cw_namespace + cw_metric_name + cw_stat for CloudWatch metrics and es_index paired with kql_filter for ElasticSearch. This goes far beyond the bare schema field names.
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 and resource: 'Add a panel to a dashboard.' It then enumerates five concrete panel shapes, making the tool's purpose unmistakable and distinct from siblings like delete_panel or add_cell. This is far beyond a vague or tautological definition.
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 gives explicit guidance on when to use each parameter set via the five shapes, recommends panel_type values per shape, and warns that datasource_id is required for metric/log panels but never for text panels. This is actionable and leaves little to inference.
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

Sciple Platform MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Sciple Platform MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/sciple-idp/sciple-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sciple-idp/sciple-mcp)

Score Badge

Copy to your README.md:

[![Sciple Platform MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/sciple-idp/sciple-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sciple-idp/sciple-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/sciple-idp/sciple-mcp'

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