designsafe-mcp

by kks32

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or workflow step, from planning and search to job submission and provenance. The three search tools are clearly differentiated by corpus, and the planning tools are separated by domain.
Naming Consistency4/5
Most tools follow a verb_noun pattern (search_snippets, build_job_request, list_queues), but a few are noun-style (supported_capabilities, calibration_options, opensees_matrix) and 'job_status' uses noun_noun. This is mostly consistent but not uniform.
Tool Count2/5
At 27 tools, the server is over the 25 threshold for 'too many'. While each tool has a distinct role, the number feels heavy for an agent to navigate, and several could be consolidated (e.g., listing tools).
Completeness4/5
The server covers the full lifecycle from planning through provenance, including search, calibration, and job management. However, it lacks a cancel/stop job tool, which is a common operation in HPC workflows.
Average 3.8/5 across 27 of 27 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 42 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
No annotations are provided, so the description must carry the full burden. It hints at read-only behavior ('List', 'return') and a constraint ('small text file'), but it does not disclose permissions, behavior for larger files, error conditions, or the output format. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, the lack of structure (e.g., separating the two modes) contributes to ambiguity, so it loses a point.
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?
With no annotations, no parameter explanations, and a dual-purpose description, the tool is not adequately specified. An output schema exists but does not compensate for missing input semantics and usage context. The agent cannot reliably decide when to call this tool or how to construct the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (path and uuid) with zero description coverage. The description does not explain what either parameter means, how they relate to the two operations, or which is required for which mode. The agent has no way to correctly populate the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states two possible actions: 'List the job archive' and 'return a small text file's content.' However, 'job archive' is ambiguous and the dual-purpose nature is not clearly separated. It does not distinguish itself from sibling tools like list_my_jobs or job_status, making the purpose only partially clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, no exclusions, and no prerequisites. The description simply states what it does without any context on the appropriate usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. While the tool is clearly a read-only status check, the description does not disclose expected outcomes, error conditions, or any side effects. It adds minimal behavioral context beyond what the tool name implies.
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 and front-loaded, using a single sentence to convey the core purpose. It is not padded with unnecessary information, though it could benefit from slight elaboration without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, output schema provided), so the description covers the basic purpose. However, it lacks contextual guidance about when to call it relative to other job-related tools and what to expect from the output, making it only minimally complete for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'uuid' with no description, and the tool description also fails to explain that this is the job ID. Schema description coverage is 0%, and the description does not compensate by clarifying the parameter's meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the current Tapis status of a submitted job. It identifies the resource (submitted job) and the specific aspect (status), which is sufficient to distinguish it from related tools like get_results, though it lacks an explicit verb like 'get' or 'retrieve'.
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_my_jobs or get_results. It does not mention prerequisites, exclusions, or a preferred context, leaving the agent to infer usage purely 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It does not mention read-only nature, required permissions, potential errors, or any side effects. It only states what output content is, not how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded with the main idea, though it could incorporate more useful detail 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 the tool's low complexity (one parameter) and presence of an output schema, the description is minimally adequate but leaves ambiguity around 'real interface' and does not frame when or how to use the tool. It is a borderline viable description with clear 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?
The description mentions 'inputs, parameters, defaults' as part of the output, but it does not explain the required input parameter 'app_id'. The schema has 0% description coverage, and the description fails to add meaning beyond the parameter's title.
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 conveys that the tool provides the app's interface definition from Tapis, including inputs, parameters, and defaults. It is clear in function and distinct from sibling tools like describe_material, though it lacks an explicit verb.
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 vs alternatives, nor any context such as prerequisites or typical use cases. The description is purely definitional with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only notes that the schema is introspected and the tool is generated, but says nothing about whether it is read-only, what the output structure looks like, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that convey the core purpose and a relevant caveat about its generated nature. It is appropriately compact, though the second sentence could be seen as extra context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool with an output schema, the description is minimally sufficient. However, it lacks any mention of how this tool fits into the dapi workflow or when an agent should invoke it, leaving some contextual gap given the large sibling set.
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 is empty. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool returns the names of app templates that ship with dapi. While it lacks an explicit verb like 'lists', the meaning is unambiguous and distinguishes it from sibling tools like describe_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any exclusions mentioned. The description simply states what it does without contextualizing its role in the broader workflow.
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 responsibility for behavioral disclosure. It only states that it uploads and returns a URI, without explaining side effects (e.g., whether the upload is persistent, overwrites, or requires authentication). The meaning of 'once' is ambiguous, and no details about the tapis:// URI's lifespan or format are 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 a single, front-loaded sentence with no filler or repetition. Every word contributes to stating the core purpose and output, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no annotations, and an output schema that the description does not explain, the description is incomplete. It omits crucial context about the expected local folder structure, the meaning of app_id, the URI returned, and any side effects or prerequisites, which is inadequate for an agent to use it confidently.
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 0% description coverage, so the description must compensate. It clarifies 'local_dir' as the local folder, but completely ignores 'app_id'. The description does not explain how the two parameters interact or what the default 'python-s3' app means, leaving users to guess.
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 identifies the tool's action ('Upload a local folder'), the resource (local folder), and the outcome ('return the tapis:// URI to run from'). This is specific and distinguishes it from sibling tools like submit_job or get_results, making it immediately recognizable as a staging operation.
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 does not mention prerequisites, use cases, or exclusions, and does not reference any sibling tools. The phrase 'once' hints at a one-time operation but lacks practical 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, the description carries the behavioral disclosure burden. It discloses that the tool does not spend SU (implied by 'before any SU is spent') and focuses on validation, but it does not explain error handling, return value structure, or whether it has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the core function and context. Every word is purposeful, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a job submission workflow and lack of annotations, the description is too sparse. It does not explain what specific sanity checks are performed, how to interpret results, or how this step relates to sibling tools like build_job_request or submit_job.
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 zero description coverage, and the description only vaguely references 'input existence' without explaining the structure or requirements of the 'job' object. This provides minimal guidance beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Schema and sanity checks plus input existence,' which is a specific verb+resource combination. It distinguishes this tool as a validation step in the job workflow, though it does not explicitly name sibling alternatives.
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 'before any SU is spent' provides a clear temporal context for when to use this tool. However, it does not explicitly state when not to use it or mention alternative validation tools, so it falls 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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the calculation formula (nodes x hours) and attributes it to guidance, but it does not mention whether the operation is read-only, how errors are handled, or what data the job object must contain. Partial transparency 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 a single concise sentence that front-loads the essential formula and references guidance. Every word earns its place, with no redundancy or filler.
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 cost estimator, the description provides the core calculation and a reference, and the presence of an output schema covers return values. However, it is incomplete because it does not explain what the 'job' object must contain (e.g., fields for nodes and hours), and no behavioral or usage details are provided.
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 one 'job' object with no property descriptions (0% schema description coverage). The description adds meaning by indicating nodes and hours are key cost factors, but it does not explicitly map these to fields inside the 'job' object or state whether they are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates SU cost based on nodes and hours, giving a specific formula. It distinguishes itself from sibling tools that build, validate, or submit jobs. However, it lacks an explicit verb like 'estimates' and reads more as a noun phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by referencing the DesignSafe job-resources guidance, implying it should be used for cost estimation according to that guidance. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites.
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 behavioral disclosure. It clearly states that unanswered facts become open questions, which is a key behavioral trait. It also explains the meaning of three boolean parameters, adding valuable context. It does not mention side effects or permissions, but as a planning tool those are likely minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into a brief opening statement followed by parameter explanations. It is fairly concise and front-loaded, but the parameter explanations take up several lines. Every sentence adds value, and there is no fluff, though it is slightly longer than strictly necessary.
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 output schema exists, so the description need not explain return values. The description provides useful context for the three booleans and the open-question behavior, but it leaves the 'request' parameter and the role of material_model/n_uncertain_parameters under-specified. Overall, it is adequate but has clear gaps for a 6-parameter tool with no schema descriptions.
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, so the description must compensate. It clarifies the semantics of uncertainty_required, quofem_wrappable, and screened well, but leaves request, material_model, and n_uncertain_parameters without any explanation. The names are somewhat self-explanatory, but the description only partially compensates for the total lack of schema-level 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 tool's function: 'Plan a calibration study from the method matrix.' This is a specific verb+resource combination that distinguishes it from general simulation planning. However, it does not explicitly contrast with the sibling tool 'calibration_options', so there is some ambiguity about how they differ.
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 'Pass what you know; unanswered facts come back as open questions' gives a practical usage pattern and explains the tool's behavior with partial inputs. However, it does not explicitly state when to use this tool over alternatives, nor when not to use it. The usage context is implied rather than fully articulated.
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 adds valuable context that snippets are executed, self-checking notebooks with pinned versions, and that the corpus only contains passing tests. This informs the agent about data quality, but does not cover other behavioral aspects such as pagination, error handling, or access 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 two sentences, front-loaded with the primary action, and every word adds value. It avoids fluff and effectively communicates the core functionality and key corpus characteristics in a compact form.
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 existence of an output schema, descriptions of return values are unnecessary. The description covers the essential purpose and a distinguishing data-quality trait. However, incomplete parameter semantics and lack of usage exclusions leave minor gaps for correct invocation.
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. It only indirectly references 'query' ('matching a query') and provides no explanation for the `app_id` parameter or query syntax. The description adds minimal value over the bare schema titles, failing to clarify parameter constraints or usage.
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 'Find' with a clear resource: 'tested, version-pinned workflow snippets matching a query.' It distinguishes from sibling tools like search_community and search_docs by emphasizing 'workflow snippets' and the tested/pinned nature, making the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reliable, pre-tested snippets ('only entries whose test passed are in the corpus'), which suggests a niche compared to generic search tools. However, it does not explicitly state when to use this tool versus siblings like search_docs or search_community, nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a human-review prerequisite and the return token, but does not mention whether approval is revocable, what happens with invalid/already-approved jobs, or permissions needed.
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, front-loaded sentences give the core purpose and the critical safety precondition. There is no filler or redundant repetition of schema/annotation 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 description covers the tool's purpose, key prerequisite, and return value, which is adequate for a focused approval step. However, the lack of parameter details and unspecified behavior for error cases leaves gaps, especially without annotations to fill in the missing context.
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 provides only a generic 'job' object with additionalProperties true and no property descriptions, and schema description coverage is 0%. The description adds no detail about the object's required fields or how to construct/reference it, only that it must be the exact job request.
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 clearly states the action ('Record human approval'), the target ('exactly this job request'), and the distinctive outcome ('returns the token submit_job requires'). This distinguishes it from sibling tools like validate_job or submit_job.
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 specifies a mandatory precondition: the harness must show the trust summary to a human before calling. It also implies when to use it by noting the token is required by submit_job, though it does not explicitly name alternatives 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 behavior disclosure. It says what it returns (list of methods with attributes) but does not mention whether it is read-only, requires authentication, or has side effects. As a listing tool, the risk is low, but the description does not explicitly assure safety or describe any potential quirks.
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, well-structured sentence that front-loads the primary purpose ('Every calibration-stage method runnable on DesignSafe') and then lists the included attributes. Every word earns its place, and there is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple enumeration tool with no parameters and an existing output schema, the description is sufficiently complete. It explains the content and scope of the tool. However, it does not explicitly place the tool in the larger workflow (e.g., that it serves as input to planning), but this is not essential given the output schema and simple nature.
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 baseline is 4. The description adds nothing about parameters, but there is nothing to add. The schema already shows an empty properties object, and the description's mention of what is returned is sufficient for a parameterless tool.
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 function: listing every calibration-stage method runnable on DesignSafe, including its engine, return value, and status. This is specific and distinguishes it from sibling tools like 'plan_calibration' which likely plans rather than lists. The resource and scope are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is a reference for available calibration methods before planning, nor does it exclude other tools. The usage context is only implied, not explicitly stated.
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 convey behavioral context. It discloses the refusal behavior for missing or mismatched tokens, which is useful. However, it does not mention whether submission is a mutating operation, any permission requirements, or what happens on success.
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, front-loaded with the primary action. Every word adds value, with no redundancy or extraneous 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 description specifies the essential token prerequisite but leaves the job parameter undefined. It relies on the reader's understanding that the job was validated elsewhere, which is reasonable but not fully self-contained.
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 should enrich both parameters. It only clarifies approval_token by linking it to approve_submission; the job parameter remains opaque with no structure, examples, or references to build_job_request or validate_job.
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 identifies the tool's function with the verb 'Submit' and the resource 'validated job'. The refusal condition adds specificity and distinguishes it from sibling tools like validate_job and approve_submission.
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 a workflow: the job must be validated and an approval token from approve_submission is required. It explicitly names approve_submission, providing a clear precondition, but does not mention alternatives or when not to use the 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 states the action without explaining side effects, prerequisites beyond the trigger, or what the output looks like. The term 'rebuild' implies potential cost but no details are given.
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 concise sentence with no filler. It front-loads the essential information and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is reasonably complete for its intended use. However, it lacks any notes on the operation's potential duration, side effects, or assumptions, which leaves some contextual gaps for an agent to assess.
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?
This tool has zero parameters, so a baseline of 4 is appropriate. There is nothing for the description to add beyond the schema, and the schema is complete with an empty parameters object.
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 'Rebuild' with the resource 'index' and adds the context 'after mirroring new notebooks or references.' This clearly distinguishes it from sibling tools like corpus_status or describe_material.
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 'after mirroring new notebooks or references' gives a clear condition for when to use this tool. It does not explicitly mention alternatives or when not to use it, but the requirement is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and explicitly discloses that the tool compiles and returns a pipeline without running the contained jobs. It adds that output includes 'deterministic archives' and 'resolved edges,' giving useful context about the non-mutating preview behavior, although it does not discuss failure modes or permissions.
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 and front-loaded with purpose, followed by a compact tasks format and a one-line output summary. The pseudo-code block is somewhat informal but still concise and scannable; no unnecessary prose is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the workflow-DAG complexity and absence of schema/parameter descriptions, the tool still needs more context to be fully self-sufficient. The output schema covers return details, but the description lacks relationship to sibling validation/submission tools and does not clarify the 'name' parameter or how to construct a complete 'job' object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description compensates by specifying the tasks element shape: task_id, job, depends_on, and optional input_from. However, it does not explain the required 'name' parameter or the meaning of 'job' and 'suffix,' leaving part of the parameter semantics implicit.
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 action-verb phrase 'Compile a DAG of job requests without running it,' clearly identifying the resource (a DAG of job requests) and the non-execution scope. This distinguishes it from running/submitting siblings and from build_job_request, which targets a single job rather than a workflow DAG.
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 'without running it' establishes the primary use case: a preview/compilation step before execution. It implies that execution tools like submit_job or job_status are not appropriate for this stage, though it does not explicitly name alternatives or exclusion criteria.
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 transparency burden. It discloses that the tool returns information from a manual and that it answers questions about parameters, sensitivities, and calibration order. This implies a read-only, informational behavior. However, it does not mention potential edge cases (e.g., unsupported model names) or the output format 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 two sentences, front-loaded with the core content. The first sentence summarizes the tool's output, and the second provides usage context. No unnecessary words 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 the tool's simplicity (one parameter, output schema present), the description adequately covers what the tool does, when to use it, and the kind of information it provides. It does not explain the return structure, but the output schema likely covers that. A minor gap is the lack of any qualification about model compatibility or prerequisites, but it is not critical for this straightforward lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'model' parameter with no description (0% coverage). The tool description refers to a 'constitutive model,' which implies the parameter identifies the model to describe. This is adequate but adds no explicit details about the format, allowed values, or examples. Since the schema provides no semantics, the description gives just enough context but could be richer.
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 function: it provides 'Parameters, sensitivities, and the calibration sequence for a constitutive model.' It specifies the source ('transcribed from its manual with page citations') and the intended position in the workflow ('Use this before planning a calibration'), distinguishing it from sibling tools like plan_calibration and calibration_options.
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 explicit guidance: 'Use this before planning a calibration.' This places it in a clear context relative to planning and calibration workflows. However, it does not name alternatives or state when not to use the tool, which would make it 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 the burden. It discloses that the tool returns a structured table, a matrix with legend, and an image path, indicating a read-only, side-effect-free operation. It does not mention limitations or permissions, but for a static lookup tool, 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?
The description is front-loaded with the purpose and consists of two concise sentences. Every clause contributes necessary information, with 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?
Given the tool's simplicity (no parameters, output schema exists), the description adequately covers what the tool does and what it returns. It even mentions the slide image path for display, adding detail beyond the schema. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description adds value by explaining what the output contains (variant table, matrix, image path), which is appropriate since there are no parameters to document.
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 identifies the tool as a reference for selecting OpenSees variants. It uses the specific verb 'Returns' and enumerates exactly what is provided (variant table, scope x platform x interface matrix, legend, and slide image path), distinguishing it from siblings like search_docs.
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 use when the user needs to know 'which OpenSees to use when,' but does not explicitly contrast with alternative tools or state when not to use it. There are no named alternatives or exclusions, so the guidance is implied rather than explicit.
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 disclosure. It reveals that None values are inferred only when unambiguous and otherwise surfaced as open_questions, warns against overriding app_id, and instructs the agent to compose cells from the returned snippet. This goes beyond generic safety hints and provides actionable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a concise behavioral contract, and a compact list of enum values. Every sentence adds value, and there is no repetition of schema fields that are already obvious from titles.
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 complexity (7 parameters, output schema, sibling planning tools), the description covers the core usage rules, inference behavior, and key constraints. It could be more complete by explicitly naming when to use plan_simulation versus plan_calibration, but the provided context is sufficient for most planning scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage, so the description must compensate. It adds meaning by explaining that optional parameters are 'facts you know' and can be left None for inference, and it lists allowed values for model_language and parallelism. However, it does not explain the semantics of n_cases, pipeline, has_allocation, or uq_or_calibration, leaving gaps.
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 'Plan an OpenSees/quoFEM simulation from the decision matrix,' which names a specific verb, resource, and domain. It clearly distinguishes from sibling tools like plan_calibration by specifying simulation rather than calibration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to invoke the tool ('Pass the facts you know...'), but it does not explicitly state when to choose this tool over alternatives such as plan_calibration. The context is clear, but no direct exclusion or comparison with sibling tools is provided.
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 adds meaningful behavioral context: results carry source/index stamps, the backend is a local index over live-fetched docs, and the Ask AI knowledge graph will replace it. It does not explicitly state read-only behavior or auth requirements, but for a search tool the absence of side effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, with a clear first sentence and two short paragraphs. However, the second sentence is dense, bundling three distinct ideas (orchestration restriction, result stamps, backend details) which could be separated for clarity. Still, 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?
Given the tool's moderate complexity and the presence of an output schema, the description covers the scope, the grounding-only usage, result characteristics, and backend implementation. It does not explicitly describe the output structure, but the mention of 'source and index stamp' and the existing output schema mitigate that. Overall, it provides enough context for an agent to use the tool correctly.
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 input schema has 0% description coverage, and the tool description does not describe the 'query' or 'limit' parameters beyond their names and defaults. It does not explain query syntax, what the limit controls, or how results are ordered. The description adds no parameter-level meaning.
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 begins with 'Search the documentation corpus' and enumerates the specific sources (dapi user guide, ds-workflows book, SimCenter quoFEM docs, reference manuals). It explicitly distinguishes itself from search_snippets by clarifying that this tool is for grounding, not for composing runs.
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 guidance: 'Grounding only, never the source of orchestration code' and points to snippets as the only source for composing runs. This clearly delineates when to use this tool versus the sibling search_snippets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: the tool 'Refuses incomplete provenance' and explains the prerequisites for success. This goes beyond a simple write operation, though it stops short of mentioning file-writing side effects or output 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 three sentences long, each earning its place: the first states the core action, the second details validation constraints, and the third provides a rationale. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters and no annotations, the description provides sufficient context about the purpose and the conditions for use. An output schema exists, so return-value details are not needed. The mention of uuid belonging to a submitted job suggests workflow placement, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning to two key parameters: 'job' (must be fully built with app, name, resources, inputs) and 'uuid' (must belong to a server-submitted job). However, it leaves snippet_ids, out_path, and estimated_su unexplained, with only out_path being self-explanatory.
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 function with a specific verb and resource: 'Emit the provenance manifest that makes the run reproducible.' This distinguishes it from sibling tools like build_job_request or validate_job, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context by stating that the job must be a fully built request and that the uuid must belong to a submitted job. This tells the agent when the tool is appropriate, though it does not explicitly name alternative tools or exclusions.
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 full responsibility for behavioral disclosure. It clearly states that nothing is submitted (non-mutating), that it mirrors ds.jobs.generate and returns a dict for inspection, and it provides a specific behavioral nuance about SimCenter apps not needing script_filename. This gives a clear picture of side effects and return value.
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 three sentences, front-loaded with the core purpose, then adds two crucial pieces of context. Every sentence provides distinct value: purpose, behavior/return, and a critical app-specific caveat. There is no fluff 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?
The description covers the essential context: what it does, that it does not submit, what it returns, and an important app-specific parameter behavior. Given the tool's moderate complexity (12 params, but most with sane defaults) and the existence of an output schema, this is sufficient for an agent to decide when to use it and what to expect, though it omits any mention of required permissions or error conditions.
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% (no parameter descriptions in the schema), so the description must compensate. It only adds meaning to one parameter (script_filename) via the SimCenter note, while the other 11 parameters rely on titles and defaults alone. This is insufficient for a 12-parameter tool with no other 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 starts with 'Build a complete Tapis job request from the app definition,' which clearly states the verb (build), the resource (job request), and the source (app definition). It distinguishes itself from siblings like submit_job and validate_job by emphasizing this is a build action, not a submission or validation.
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 'Nothing is submitted,' which tells the agent when NOT to use this tool (for actual submission) and implies it should be used for inspection before submitting. It also gives specific guidance for SimCenter apps regarding script_filename, but does not explicitly name alternative tools like submit_job for the actual submission step.
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 full burden. It discloses ordering (newest first), client-side filtering, defaults (limit 100), output formats, verbose flag, list_type semantics, and raises JobMonitorError on API failure. This is extensive and valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary, detailed Args section, Returns/Raises, and an example. It is slightly verbose but every section earns its place, and the front-loaded summary helps.
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 has 6 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers parameter semantics, return types based on output, error behavior, and gives usable examples. No significant gaps remain.
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. It explains every parameter in detail: app_id, status, limit, output, verbose, and list_type with defaults and behavior. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists jobs with optional filtering, and mentions fetch order. However, it does not explicitly distinguish itself from sibling tools like job_status or get_results, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the title and description (listing jobs), and the parameter details give hints. But there is no explicit when-to-use or when-not-to-use guidance compared to alternatives, and no mention of when to prefer this over other job-related tools.
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 transparency burden. It discloses return formats ('df' vs 'raw'), example output fields (name, maxNodes), and notes that the tool is generated, which is useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into Args, Returns, and Example sections, with no filler. The generated-tool note adds useful context and is clearly marked, though it adds a slight preamble.
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 operation with no output schema, the description provides sufficient information about inputs, outputs, and invocation. It lacks deeper error/auth details, but those are less critical for this type of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly defines both parameters, including a concrete example value for system_id and the optional 'output' choices. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'List batch queues available on a Tapis execution system.' This clearly distinguishes it from sibling tools like list_systems and list_app_templates.
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 the required system_id and provides a usage example, making it clear when to call this tool. It does not explicitly mention alternatives, but the scope is evident from the resource it targets.
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 that results include matching text, source path, and an index build stamp, indicating output freshness, and implicitly a read-only operation. It also notes that coverage can be checked via corpus_status(), which is a useful limitation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that front-load the core purpose, then explain the value of the return payload, and finally provide usage alternatives. Every sentence contributes meaningful information without redundancy or 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?
The description covers purpose, return context, and a sibling alternative, and the existence of an output schema reduces the need to detail return shape. However, it could mention prerequisites or relationship to search_snippets, and the 'every' claim is subtly tempered by the corpus_status() reference.
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 does not explain the meaning or expected format of 'query' or the behavior of 'limit'. The parameter names are self-explanatory to some extent, but no additional semantic details are provided, leaving ambiguity about query syntax or result count handling.
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 action ('Search every local notebook, model, and script for aligned passages') and clearly differentiates from siblings by recommending search_docs for documentation-only search. It covers what is searched and the scope.
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 instructs when to call corpus_status() to review index coverage and when to use search_docs, providing clear alternatives and context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool writes to corpus/, excludes CommunityData due to Tapis auth requirements, and requires a reindex afterward. However, it does not explicitly state whether it overwrites existing files, requires network/GitHub access, or any failure modes, leaving some behavioral traits implicit.
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 three sentences that each add value: purpose/context, parameter explanation, and exclusion/next-step. It is front-loaded with the main verb and resource, with no filler or redundant content.
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 tool with an output schema, the description covers purpose, parameter usage, exclusions, and post-conditions (reindex). It omits only niche details like the list of valid source names or explicit network requirements, but is otherwise sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a name 'source' with no description, but the description compensates by explaining the parameter semantics: 'fetch just one logical source by name; empty fetches every GitHub-backed source.' This clarifies the default behavior and scope of the parameter, though it doesn't enumerate valid source 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 action ('Fetch grounding sources live from their canonical GitHub repos into corpus/') and the context ('for deployments without local checkouts'). It also differentiates from sibling tools by noting what it does not handle (CommunityData) and the follow-up action (reindex).
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 when-to-use context ('for deployments without local checkouts') and an explicit exclusion ('CommunityData is not fetched here; needs Tapis auth; see corpus_status'). It also provides next-step guidance ('Run reindex after'), covering both alternatives and follow-ups.
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 for behavioral disclosure. It reveals important behavior: entries have test status, untested capabilities have a human approval gate, and out-of-scope requests should be declined. It does not describe the exact output structure, but an output schema is present so that burden is reduced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place. The first sentence states the core purpose, the second adds critical usage constraints, and the third gives an explicit fallback behavior. It is front-loaded and free of 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?
Given the tool has zero parameters, an output schema, and a clear one-line purpose, the description is complete. It covers when to consult it, how to interpret test status, and what to do for requests outside the supported map, leaving no important selection or invocation gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter-specific semantics because none are needed; it focuses on the meaning of the returned capability information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool reports what the server supports by scientific domain, which establishes it as a capability-discovery resource. The verb is implied rather than explicit, but the first sentence is unambiguous and distinguishes it from sibling tools focused on jobs, calibration, and searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to consult this before making promises and instructs that out-of-map requests should be declined by referencing out_of_scope. It also warns that 'candidate' and 'untested' entries require human-run graduation before unattended use, giving clear when-to-use and 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the default filtering behavior, the 'all' option to override it, and the return format (DataFrame or dicts with specific fields). This adds meaningful context beyond just the tool name.
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 with clear sections for purpose, arguments, returns, and examples. It's slightly longer than necessary due to the meta-note about auto-generation, but every instructional sentence earns its place, and the examples are highly illustrative.
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 tool with two optional parameters, no annotations, and no output schema, the description thoroughly covers purpose, behavior, parameters, return format, and usage examples. Nothing important is missing for an agent to select and invoke this 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?
The schema has zero description coverage, so the description fully compensates. Both parameters ('category' and 'output') are explained in detail with accepted values and defaults, and examples demonstrate usage. This goes well beyond the schema's bare property 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 opens with 'List Tapis systems you have access to.' which is a specific verb+resource pairing that immediately clarifies the tool's function. It also distinguishes itself by noting the default filtering of internal and project-specific systems, setting it apart from generic system listing 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 clearly explains the context for use (listing systems you have access to) and provides examples for each category option. It doesn't explicitly mention alternative tools or when not to use it, but the context is clear enough given the sibling tools are mostly unrelated to listing systems.
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?
Without annotations, the description carries the burden of behavioral disclosure. It explains the significance of an absent source (degraded grounding) and advises how to respond, which is valuable context. It does not explicitly state read-only behavior, but the nature of a status query 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 description is a single, well-structured sentence with a colon-separated list of the exact aspects covered. It is concise, front-loaded with the purpose, and contains no 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?
Given the output schema exists, the description does not need to explain return values. It covers all key aspects: what the index covers, where it came from, resolution status, passage counts, build time, and how to handle absent sources—linking to fetch_corpus as a follow-up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (no params). The baseline for a zero-parameter tool is 4; the description correctly focuses on behavior 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 explicitly states what the tool reports: the grounding index's coverage (logical sources), resolution state (local checkout, fetched cache, absent), passage counts, and build time. This specific enumeration distinguishes it from sibling tools like fetch_corpus, which modify state.
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 provides clear usage guidance: if a source is absent, say grounding is degraded rather than answering from partial knowledge, and use fetch_corpus() to fill the gap. This explicitly names the alternative and the condition for using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![designsafe-mcp MCP server](https://glama.ai/mcp/servers/kks32/designsafe-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kks32/designsafe-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/kks32/designsafe-mcp'

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