Skip to main content
Glama

WORKS Public Verifier

by io.github.DYZCODE

Check WORKS verification eligibility

works_public_eligibility
Read-onlyIdempotent

Fast deterministic preflight for tool-only clients. Call this before any other WORKS tool when eligibility is uncertain, especially for mutable or abbreviated refs, local or private repositories, and build, test, runtime, deployment, or production claims. It does not download a repository or persist data. If eligible is false, stop without calling verification.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimYesUse static-evidence for generic signed or static repository evidence; it maps conservatively to node-package. Never use it for build, tests, runtime, deployment, or production claims.
referenceNoReference exactly as supplied; never expand a branch, tag, or short SHA.
source_kindYesClassify where the requested source lives.
repository_urlNoExact repository URL supplied by the user, if any.
repository_visibilityYesUse public only when the request identifies a public repository.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonYes
reportYes
contractYes
eligibleYes
next_toolYes

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds crucial behavior: it is 'fast deterministic', 'does not download a repository or persist data', and instructs to halt on false eligibility. These go beyond the annotations and give the agent concrete expectations.

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

Conciseness5/5

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

Four short sentences, each with clear purpose: nature of tool, when to call, side-effect guarantee, and stop condition. Front-loaded with 'Fast deterministic preflight' and no redundant words.

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

Completeness5/5

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

The description covers purpose, usage context, side effects, and control flow. Since an output schema exists, it doesn't need to explain return values. The guidance is sufficient for an agent to decide when to invoke and what to do with a false result.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all parameters, including enums for claim, source_kind, and repository_visibility. The description adds contextual guidance about which parameter values matter (e.g., abbreviated refs, private repos) but does not add syntax or format details, so it stays at the baseline for high coverage.

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 identifies the tool as a 'preflight' eligibility check and states it should be called before any other WORKS tool, clearly distinguishing it from the sibling verification and lint tools. It names the specific resources (mutable/abbreviated refs, local/private repositories, claim types) it handles.

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

Usage Guidelines5/5

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

Explicitly instructs when to use this tool: before any other WORKS tool when eligibility is uncertain, with specific scenarios listed (mutable/abbreviated refs, local/private repos, build/test/runtime/deployment/production claims). Also provides a clear stop condition: 'If eligible is false, stop without calling verification.'

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

All WORKS Public Verifier toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct role: works_public_eligibility is a preflight check, works_public_contract_lint resolves the contract digest, and works_verify_public_repository performs the actual verification. The descriptions explicitly specify the intended order and conditions, so an agent can easily select the right tool.

Naming Consistency3/5

All tool names share the 'works_' prefix, but the pattern is inconsistent: two use 'public' as a scope modifier (works_public_eligibility, works_public_contract_lint), while the third places 'public' after the verb (works_verify_public_repository). Additionally, 'eligibility' is a noun, 'contract_lint' can be read as noun_verb, and 'verify_public_repository' is verb_noun, creating mixed conventions.

Tool Count5/5

With only 3 tools, the server is tightly scoped to its purpose: preflight eligibility, contract resolution, and final verification. Each tool is necessary and non-redundant, making the count well-suited for the domain.

Completeness4/5

The tools cover the full workflow from eligibility check through final verification, and the descriptions provide clear guidance on when to stop. A minor gap is the lack of an explicit tool to list supported static claims, but this can be inferred from the contract_lint and verify tools, so the overall surface is functional.

Resources