smplkit MCP Server

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 job kind is inferred, the URL must be public, and for recurring jobs a test via 'run_job' is recommended. However, it does not discuss authorization, rate limits, or potential 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two paragraphs, front-loaded with the main purpose. Every sentence adds value, and there is no redundancy or wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 12 parameters and an output schema (which handles return values), the description covers creation behavior and post-creation steps adequately. It is complete for an agent to understand the main workflow, though some edge cases (like error handling) are not covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds context about the kind being inferred and the URL requirement, but most parameter details are already well-documented in the schema. No significant additional semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a scheduled HTTP job and distinguishes it from siblings like 'update_job' and 'run_job'. It specifies the verb 'create' and the resource 'scheduled HTTP job', with additional context on how the job kind is inferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidelines on when to use each schedule type (recurring, one-off, manual) and notes that the URL must be publicly reachable. It also advises calling 'run_job' after creating a recurring job. No explicit when-not, but 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosure. It reveals that run history is retained and the id may be reused, which adds important behavioral context beyond the delete action. However, it does not mention any permissions or irreversible effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the core action and adding a succinct behavioral note. No wasteful language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete operation with one parameter and an output schema, the description covers the essential behavioral aspects (history retention, id reuse) adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'job_id' is fully described in the input schema. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Delete a job' with a specific verb and resource, and adds behavioral nuance about history retention and id reuse, which differentiates it from sibling tools like create_job or update_job.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating the action, but does not explicitly provide context for when to use this tool versus alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 indicates the tool returns configuration details but does not mention authentication needs, rate limits, or potential side effects (none expected for a read operation). The description is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys the tool's purpose without any extraneous information. Every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one required parameter) and the presence of an output schema, the description adequately covers what the tool does. It mentions the key elements of the configuration (schedule, target request, environments).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single parameter job_id. The description does not add any additional semantic meaning beyond what the schema provides, adhering to the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a single job's full configuration including schedule, target request, and environments. It uses a specific verb ('Get') and resource ('one job'), distinguishing it from sibling tools like list_jobs (which lists multiple jobs) and get_run (which retrieves a run).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when needing complete configuration of a specific job. However, it doesn't explicitly state when not to use it or provide alternatives. Sibling tool names like list_jobs and get_run provide context, but the description itself lacks explicit usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the content returned (status, timings, failure reason, captured HTTP response) and notes the 'result' field. No annotations provided, but the description covers the tool's read-only nature implicitly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with key details front-loaded. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that output schema exists, the description adequately covers the tool's purpose and return content. Complete for a simple get operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter description. The tool description adds no new meaning beyond the schema for the run_id parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it gets one run and lists the specific data it returns (status, timings, failure reason, HTTP response). Distinguishes from sibling 'list_runs' which lists runs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use case for retrieving details of a specific run, but no explicit guidance on when to use vs alternatives like list_runs. Missing exclusion scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden. It discloses that each job includes schedule, target request, and a last_run summary with status and HTTP status. The word 'list' implies a read-only operation, and the enrichment detail adds transparency. It does not mention authentication or pagination, but for a simple list 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose and enrichment, second gives use case and output details. No wasted words, front-loaded with key information. Very concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the output content (schedule, target, last_run) and use case. With an output schema present, return format details are handled. It omits ordering or pagination behavior, but for a list tool this is not critical. Overall, adequate for the complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all three parameters have descriptions in the schema). The tool description adds no additional parameter information beyond what the schema already provides. Baseline is 3 for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists configured jobs enriched with their latest run, distinguishing it from sibling tools like get_job (single job) and list_runs (runs). The verb 'list' and resource 'jobs' are specific, and the enrichment with latest run is a key differentiator.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: 'Use this to see what's scheduled and whether each job's most recent run succeeded or failed.' This implies when to use it, but does not explicitly exclude alternatives (e.g., for a specific job's details use get_job). The context signals and sibling names help, but the description itself lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains filtering behavior and gives examples, but does not detail pagination limits, default ordering, or performance characteristics. This is adequate but could be more thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and key usage patterns. Every sentence adds value with no waste or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters and the presence of an output schema, the description covers main use cases (filtering, monitoring, job history) but does not elaborate on every parameter. It is complete enough for an agent to query effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds some value by explaining the 'failed_only' shortcut and usage patterns, but largely restates filter capabilities already in the schema. Does not provide deeper semantics beyond what the schema offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'runs', and specifies filtering dimensions (job, status, trigger, environment, time). It distinguishes implicitly from siblings like 'get_run' and 'list_jobs' by focusing on run listing with filters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage patterns: 'failed_only=true' for failure monitoring and 'job=<id>' for job history. This gives clear context on when to use each filter, but doesn't explicitly exclude other use cases 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description takes full responsibility for behavioral disclosure. It clearly states that the job's schedule and enabled state are unchanged, and that the run is immediate. It explains the return value includes status and HTTP response. While it does not discuss side effects like concurrent runs or error states, the core behavior is well-covered for a simple trigger tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The first sentence states the primary action; the second adds context and expected output. Every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters, one required, and an output schema (not shown but implied). The description covers the return value and notes the schedule remains untouched. It does not mention error conditions or prerequisites (e.g., job must be enabled), but these are minor omissions. Overall, it provides enough context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no additional meaning beyond the schema's parameter descriptions. The description does not elaborate on when to use 'wait' or 'environment' defaults. Baseline score of 3 is appropriate since the schema itself is descriptive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fires an immediate run of a job and returns the captured result. It specifies the returned data includes run status and HTTP response. This distinguishes it from sibling tools like get_run (which retrieves existing runs) and update_job (which modifies configuration). The purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description positions the tool as 'the way to prove a job works,' providing clear context for when to use it (testing/verification). It does not explicitly exclude other uses or mention alternatives, but the context is strong enough for an agent to infer it is for fire-once testing rather than ongoing monitoring.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains that the tool reads current job, applies change, and saves full updated job, which is valuable behavioral context. However, it does not disclose side effects like validation or potential conflicts between schedule and run_at.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no superfluous words. Front-loaded with core purpose followed by mechanism. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 14 parameters and existing output schema, the description explains the essential partial update behavior. Missing some details like parameter interactions but adequate for most use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema parameter coverage is 100%, so baseline is 3. The description reinforces partial update semantics but adds no new meaning beyond what each parameter's description provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Change a job' and the resource 'job', distinguishing it from sibling tools like create_job (new) and delete_job (remove). The example of moving to 8am reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises 'Only pass the fields you want to change', which is a clear usage guideline. However, it does not explicitly state when not to use it or compare to alternatives like create_job or delete_job.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.