A
licenseNot graded
qualityA
maintenanceLocal-first evidence-backed repository memory for coding agents, providing read-only tools to list concepts, explain them, get governed context packs, and verify claims against the codebase.
11
Apache 2.0
RepoPilot
Server Details
Repository evidence for agents before they adopt dependencies, enter codebases, compare, or merge.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
8 toolsanalyze_repoGet a repository decision briefARead-onlyIdempotentInspect
CALL when entering an unfamiliar repository or deciding whether to depend on, fork, learn from, or deploy it. Returns a concise four-use-case brief, watchouts, evidence confidence, architecture summary, freshness, and next actions without dumping the full generated artifact. Use get_artifact when file-level orientation is needed. Pass exactly one of repo or package.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Public GitHub repository as owner/repo or a github.com URL. | |
| package | No | npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior, so the description does not need to repeat safety traits. It adds useful behavioral context by stating the tool returns a concise brief 'without dumping the full generated artifact' and lists what the brief contains (watchouts, evidence confidence, architecture, freshness, next actions).
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 compact sentences front-load the call condition, then list the return value, then provide an alternative tool and a usage constraint. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, two-parameter tool with an output schema, the description covers the decision context, the differentiating alternative, the output scope, and the key input constraint. Nothing needed for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents repo and package, including examples and a version-specific alternative tool under package. The description adds the 'exactly one' exclusivity constraint, which slightly reinforces the oneOf schema but gives no deeply new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states an explicit verb and resource: analyze a repository or package to produce a decision brief. It names concrete use cases (depend on, fork, learn from, deploy) and differentiates from the sibling get_artifact by contrasting decision brief vs file-level orientation.
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 clear when-to-use triggers: entering an unfamiliar repository or deciding whether to depend on/fork/learn from/deploy it. It also provides an explicit alternative: 'Use get_artifact when file-level orientation is needed,' plus the input constraint 'Pass exactly one of repo or package.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_change_riskPrioritize review for a PR or diffARead-onlyInspect
CALL before merging a pull request or after producing a local diff. Returns a deterministic 0-10 change-shape score with receipts for size, spread, missing tests, sensitive paths, hotspots, and blast radius. Pass repo+pr OR diff; repo may accompany diff for cached hotspot context. This prioritizes review and never approves a merge.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pr | No | Positive pull request number, used with repo. | |
| diff | No | Raw unified git diff to score directly. | |
| repo | No | owner/repo or a github.com URL. | |
| files | No | Privacy-preserving changed-file facts; contains no source or diff hunks. | |
| proofs | No | ||
| base_sha | No | ||
| head_sha | No | ||
| contract_id | No | Optional short-lived contract_id returned by plan_repo_task. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: output is deterministic, it never approves a merge (limit on its authority), and it notes repo caching for hotspot context. It does not detail receipts format, but with readOnlyHint covering the safety dimension, 4 is generous but warranted.
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, front-loaded with when to call, the core value (deterministic score with receipts), input modes, and a critical behavioral caveat. Every clause carries information; zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return format needn't be detailed. The description covers invocation timing, input-mode disjunction, scoring dimensions, determinism, and non-approval semantics. It doesn't detail the receipt structure or caching behavior, but given the good annotations and output schema, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, and the description fills key gaps: it explains the input-mode semantics (repo+PR OR diff), states repo may accompany diff for cached hotspot context, and notes files array is 'privacy-preserving... contains no source' — clarifying that line counts may be placeholders. This adds meaning beyond the oneOf constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it computes a 'deterministic 0-10 change-shape score' with receipts for specific factors (size, spread, missing tests, sensitive paths, hotspots, blast radius). The verb 'check' plus resources (PR/diff) and the distinct scoring behavior distinguish it from siblings like check_dependency or analyze_repo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'CALL before merging a pull request or after producing a local diff', giving concrete timing. It lists valid input combinations ('repo+pr OR diff; repo may accompany diff') and clarifies it 'prioritizes review and never approves a merge', which sets expectations for when it's appropriate vs not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_dependencyCheck a dependency before adoptionARead-onlyIdempotentInspect
CALL when the user or agent is about to add, upgrade, trust, fork, or deploy an npm package or public GitHub repository. Returns a lean repository-level recommendation, confidence, evidence gaps, CVEs, maintenance, ownership, license, CI/tests, Scorecard, freshness, and next actions. DO NOT use for code navigation. Pass exactly one of repo or package. A favourable result does not validate an exact package version or compatibility.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Public GitHub repository as owner/repo or a github.com URL. | |
| package | No | npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive safety, and this description adds non-obvious behavioral context beyond them: the verdict is a repo-level recommendation, not a version-level validation, and a favorable result does not guarantee compatibility or an exact package version. This epistemic caveat is exactly the kind of behavioral disclosure that protects the agent from misusing the output.
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-five short sentences with zero filler: trigger conditions first, then outcome, then exclusions, then constraints/caveats. Every sentence earns its place and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a rich parameter schema (100% coverage), a full annotation set (readOnly, openWorld, idempotent, non-destructive), and an output schema, the description has very little left to explain—it covers scope, triggers, exclusions, and limitations. The agent receives everything necessary to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well documented with format hints and a sibling pointer for version checks. The description adds only 'Pass exactly one of repo or package,' which restates what the schema's oneOf already enforces, so the marginal value beyond the schema is modest.
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 clear verb+resource pair—check a dependency—and gives the concrete use case (add, upgrade, trust, fork, deploy). It enumerates the return content (recommendation, CVEs, license, Scorecard, etc.) and distinguishes itself from siblings like evaluate_dependency_change and code-navigation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit when-to-use trigger list (add, upgrade, trust, fork, deploy), includes an explicit exclusion ('DO NOT use for code navigation'), and the package schema parameter names the alternative (evaluate_dependency_change) for version-specific checks. The agent needs no inference to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_reposCompare two repository choicesARead-onlyIdempotentInspect
CALL when the user is choosing between exactly two dependencies or repositories. Returns the preferred candidate for each use case, material trade-offs, confidence, and evidence gaps. Each target is owner/repo, a GitHub URL, an npm package name, or npm:@scope/pkg. Cached full analyses are preferred; a miss uses bounded live GitHub/OpenSSF evidence with limited confidence and explicit unknowns rather than guessing.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First repo or npm package target. | |
| b | Yes | Second repo or npm package target. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, non-destructive. The description adds valuable behavioral detail beyond these: it discloses that on a cache miss it uses bounded live GitHub/OpenSSF evidence with limited confidence and explicit unknowns rather than fabricated certainty. This is honest about limitations and return variability based on cache state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with useful information: when to call, what's returned, accepted formats, and behavioral caveats. No wasted words or repetition of annotation content. Front-loaded with the trigger condition.
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?
Tool has an output schema and rich annotations, so description needn't cover return value structure. It covers trigger condition, target format inputs, evidence sourcing behavior, and confidence caveats. For a comparison tool with simple two-string inputs and disclosed fallback strategy, this is 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?
Schema coverage is 100%, so both parameters a and b are documented. The description also adds meaning by explaining accepted formats (owner/repo, GitHub URL, npm package name, npm:@scope/pkg) which extends beyond the schema's generic 'repo or npm package target'. However, it doesn't clarify dimensional/ordering semantics (e.g., whether a/b order matters) beyond what the schema provides, so a baseline 3 is appropriate.
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 compares two repository/dependency choices and lists what it returns (preferred candidate per use case, trade-offs, confidence, evidence gaps). It explicitly scopes to 'exactly two' choices, distinguishing it from single-repo analysis siblings. The accepted target formats are enumerated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to CALL ('when the user is choosing between exactly two dependencies or repositories') and implies when NOT to (single choice). It describes the fallback behavior: cached analyses preferred, bounded live evidence on miss with explicit unknowns rather than guessing. This provides strong guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evaluate_dependency_changeEvaluate an exact dependency change in project contextARead-onlyIdempotentInspect
CALL immediately before adding or upgrading an npm dependency. Answers "is this exact version safe to take on" from registry metadata, advisory deltas, provenance, license, and repository evidence, and returns blockers, warnings, a recommendation, and a verification plan. Example: {"dependency":"lodash","to_version":"4.17.21"} — every field is top-level, never nested under a "change" key. Only dependency is required — omit to_version to evaluate the latest published version, exactly as npm install <pkg> would. to_version also accepts a dist-tag ("latest") or a SemVer range ("^4.17.0"); it resolves to one exact version, reported back in change.to_version. Everything RepoPilot can infer is inferred, and every default, repair, and resolution is listed in input_adjustments. Evaluates only; never installs or edits anything.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | Optional free text describing why you are making this change. Advisory only; it changes no verdict. | |
| project | No | Optional, source-free facts about the project you are changing. Supplying it adds Node/peer/license compatibility and a command-level verification plan. Omit it entirely and compatibility comes back "unknown" - read that as not checked, never as no problem found. Every field is optional; anything missing is defaulted and reported in input_adjustments, never rejected. Never send source code. | |
| dependency | Yes | A STRING: the npm package name on its own, with no version and no surrounding object — "lodash", "@types/node". Not {"name":...}, not {"lodash":"^4.17.0"}, not a list, and never wrapped in a top-level {"change":{...}} object — every field here is top-level. The version goes in to_version, the currently installed one in from_version. | |
| to_version | No | The version you intend to install — an exact version ("4.18.1"), a dist-tag ("latest"), or a SemVer range ("^4.17.0"). A quoted string is preferred; a bare JSON number ("to_version": 19) is also accepted and read as the string "19". Omit to evaluate the latest published version. | |
| from_version | No | The version currently installed, or omitted when adding a new dependency. A bare JSON number is accepted the same way as to_version. Supplying it produces a before/after advisory comparison. | |
| policy_profile | No | Named team dependency policy. Strict requires provenance and denies package install hooks. Must be spelled exactly — a near-miss spelling is rejected rather than guessed, because reading it wrong would answer under a policy you did not ask for. | balanced |
| dependency_type | No | Where the dependency goes, in THESE words: "runtime" for a dependencies entry, "development" for devDependencies. The manifest and CLI spellings ("dev", "devDependencies", "--save-dev", "prod") are mapped onto these and reported in input_adjustments. | runtime |
| package_manager | No | Optional. Only affects the commands and lockfile named in the verification plan. Inferred from project.lockfile_path when you send a project snapshot, and assumed to be npm otherwise. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavior beyond annotations: it resolves ranges and dist-tags to one exact version reported back in change.to_version, reports all defaults/repairs in input_adjustments, treats 'unknown' compatibility as not checked, and emphasizes evaluation-only semantics. These details align with the readOnly, idempotent, openWorld annotations and substantially enrich what the agent can expect from the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place for a tool with 8 parameters and nested project objects. It is front-loaded with the immediate usage instruction, then delivers the key call semantics, example shape, defaults, and safety boundary without fluff. The density is justified by the tool's complexity.
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 invocation timing, required and optional parameters, version resolution behavior, inference and defaults, policy strictness, dependency_type mapping, package_manager inference, and the evaluation-only guarantee. Given that an output schema exists, the absence of detailed return-value documentation is acceptable, and nothing an agent needs to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the description adds crucial meaning: dependency must be a plain string with no version or wrapper object, to_version accepts exact/dist-tag/range forms with omission meaning latest, from_version triggers before/after comparisons, policy_profile must be spelled exactly, and dependency_type maps manifest/CLI spellings to canonical words. This is exactly the kind of disambiguation a schema alone cannot provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'evaluates an exact dependency change' and answers whether a specific npm version is safe based on registry metadata, advisories, provenance, license, and repository evidence. It also lists concrete outputs (blockers, warnings, recommendation, verification plan), making the tool's function easy to distinguish from the sibling tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit timing guidance: 'CALL immediately before adding or upgrading an npm dependency.' It also clarifies the boundary by saying 'Evaluates only; never installs or edits anything,' which tells the agent when not to use it as an installer. It doesn't explicitly name sibling tools or contrast them, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_artifactOrient an agent in an unfamiliar repositoryARead-onlyIdempotentInspect
CALL before substantial code work in an unfamiliar repository when the agent needs key files, entry points, architecture hypotheses, a reading order, and verify-before-trusting guidance. Returns the cached CLAUDE.md-style artifact or Cursor rules. Do not call again if the artifact is already in context. Pass exactly one of repo or package.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Public GitHub repository as owner/repo or a github.com URL. | |
| format | No | markdown for CLAUDE.md-style guidance; cursor for .mdc rules. | markdown |
| package | No | npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive behavior, and the description adds contextual grounding: the returned content is a cached artifact rather than a live repository scan and is 'verify-before-trusting' guidance. This helps set an agent's expectations about staleness and reliability beyond what the annotation flags alone communicate.
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 with four distinct jobs: when to call, what it returns, when to skip and the parameter contract. The uppercase 'CALL' opening front-loads the most important trigger condition and no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema parameter coverage, an output schema, and strong annotations, the essential decision information is present. The missing analyze_repo route contrast is the main gap, while the cached/verify guidance and output schema fill most of the remaining behavior.
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?
Parameter description coverage is 100%: the schema fully explains repo, format, and package, including example formats and the versioned-return alternative. The only new semantic in the description is 'exactly one of repo or package', which re-states what the schema's oneOf already enforces.
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 names a specific verb and resource: it 'CALLs' to return the cached CLAUDE.md-style artifact or Cursor rules for orienting an agent in an unfamiliar repository. The title reinforces the distinct purpose ('Orient an agent in an unfamiliar repository'), and the description's focus on orientation artifact distinguishes it from version-judgment and risk-analysis siblings, though it does not explicitly separate it from analyze_repo.
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?
When to call is explicit ('CALL before substantial code work in an unfamiliar repository') and the 'do not call again if the artifact is already in context' condition is a clearly stated idempotency guard. The package schema also points to evaluate_dependency_change for version-specific judgments, providing a named alternative. However, the description does not explain when to choose this over the heavily overlapping analyze_repo sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_repo_taskPlan a task against repository evidence and a checked SHAARead-onlyInspect
CALL before editing an unfamiliar public repository. Returns a bounded reading order, relevant files, dependency consumers, test/verification obligations, analyzed-vs-checked SHA relation, evidence provenance, and a short-lived verification contract. Task text is used only for bounded local matching and is never persisted raw.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Public GitHub repository as owner/repo or a github.com URL. | |
| task | Yes | ||
| intent | No | ||
| package | No | npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead. | |
| max_files | No | ||
| path_hints | No | Optional repository-relative files or directories to prioritize. | |
| checked_sha | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses meaningful behavioral details: task text 'is used only for bounded local matching and is never persisted raw,' and the verification contract is 'short-lived.' This adds real context about persistence and scope that annotations do not carry. It slightly under-specifies side effects such as rate limits or external network behavior, giving a 4 rather than a 5.
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 tightly packaged sentences: the first front-loads the call-or-not decision, the second enumerates the return contract, and the third covers the privacy behavior. There is no filler, repetition, or restating of the title.
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 a nested input schema, an output schema, and safety annotations, the description covers the core needs: when to invoke, what will be returned, the ephemeral verification contract, and the non-persistence guarantee. It stops short of describing the plan's downstream consumer workflow or caveats on open-world repo data, but nothing critical is missing for an unplanned call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 43%, so the description must partially compensate. It adds semantics for the task param ('used only for bounded local matching and never persisted'), and its mention of the 'analyzed-vs-checked SHA relation' clarifies the checked_sha param. However, it does not explain the repo-vs-package disambiguation or max_files/path_hints semantics beyond what the schema already says, leaving the description to add only modest value over the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific imperative — 'CALL before editing an unfamiliar public repository' — and then enumerates concrete deliverables (bounded reading order, relevant files, dependency consumers, test/verification obligations, checked-SHA relation). This names both verb and resource precisely and differentiates it from siblings like evaluate_dependency_change and check_dependency, which focus on versions or risk rather than up-front planning.
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 an explicit when-to-use condition ('before editing an unfamiliar public repository'), and the package parameter schema adds a clear exclusion ('to judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead'). It does not enumerate when not to use it relative to the other siblings (analyze_repo, check_change_risk), but the primary trigger is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_dependency_changeVerify a dependency change after local workARead-onlyIdempotentInspect
CALL after changing the manifest/lockfile and running local checks. Compares the exact evaluated target with the resolved result and caller-reported proof receipts, reports missing/failed evidence and residual risk, and labels receipts as caller asserted. It never runs commands or stores diff/check output.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| diff | No | ||
| after | Yes | ||
| checks | Yes | ||
| evaluation | Yes | The verification_context object exactly as evaluate_dependency_change returned it, passed back unchanged. Its signature covers every field, so edit nothing inside it. Sending the whole evaluate result instead is accepted; the receipt is read out of its verification_context. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| agent | Yes | |
| status | Yes | |
| schema_version | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds a hard safety boundary: 'It never runs commands or stores diff/check output.' It also discloses trust semantics ('labels receipts as caller asserted') and output behavior ('reports missing/failed evidence and residual risk'), which are not inferable from the readOnly/idempotent annotations alone.
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, front-loaded with the imperative CALL and the precondition; each sentence adds a distinct piece of information: when to use it, what it does, and what it avoids. No filler or repetition of schema content.
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 complex nested-schema tool, the description provides the workflow trigger, the comparison semantics, and the no-side-effect boundary. The output schema exists, so return values do not need to be described, and the evaluation parameter's schema description already covers the pass-back-unchanged requirement.
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?
With schema description coverage at only 25%, the description compensates by mapping required inputs: 'exact evaluated target' → evaluation, 'resolved result' → after, and 'caller-reported proof receipts' → checks. The optional diff parameter is not detailed, but the three required parameters receive useful semantic labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it verifies a dependency change after local work. It further differentiates from siblings by specifying the comparison inputs (evaluated target, resolved result, caller-reported proof receipts) and the outputs (missing/failed evidence, residual risk).
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 opening 'CALL after changing the manifest/lockfile and running local checks' is explicit about when this tool belongs in the workflow. It does not name alternative tools or negative conditions, but the sequencing relative to evaluate_dependency_change is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
evaluate_dependency_change5 fields changed- changed
Input schema / properties / dependency / descriptionPrevious value: -"A STRING: the npm package name on its own, with no version and no surrounding object — \"lodash\", \"@types/node\". Not {\"name\":...}, not {\"lodash\":\"^4.17.0\"}, not a list. The version goes in to_version, the currently installed one in from_version."New value: +"A STRING: the npm package name on its own, with no version and no surrounding object — \"lodash\", \"@types/node\". Not {\"name\":...}, not {\"lodash\":\"^4.17.0\"}, not a list, and never wrapped in a top-level {\"change\":{...}} object — every field here is top-level. The version goes in to_version, the currently installed one in from_version." - changed
Input schema / properties / from_version / descriptionPrevious value: -"The version currently installed, or omitted when adding a new dependency. Supplying it produces a before/after advisory comparison."New value: +"The version currently installed, or omitted when adding a new dependency. A bare JSON number is accepted the same way as to_version. Supplying it produces a before/after advisory comparison." - changed
Input schema / properties / from_version / typePrevious value: -[ - "string", - "null" -]New value: +[ + "string", + "number", + "null" +] - changed
Input schema / properties / to_version / descriptionPrevious value: -"A STRING: the version you intend to install — an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\"). Quote it even when it looks numeric (\"19\", not 19). Omit to evaluate the latest published version."New value: +"The version you intend to install — an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\"). A quoted string is preferred; a bare JSON number (\"to_version\": 19) is also accepted and read as the string \"19\". Omit to evaluate the latest published version." - changed
Input schema / properties / to_version / typePrevious value: -"string"New value: +[ + "string", + "number" +]
2 tool updates
- Changed
evaluate_dependency_change3 fields changed- changed
Input schema / properties / dependency / descriptionPrevious value: -"The npm package name on its own, with no version — \"lodash\", \"@types/node\"."New value: +"A STRING: the npm package name on its own, with no version and no surrounding object — \"lodash\", \"@types/node\". Not {\"name\":...}, not {\"lodash\":\"^4.17.0\"}, not a list. The version goes in to_version, the currently installed one in from_version." - changed
Input schema / properties / dependency_type / descriptionPrevious value: -"Where the dependency goes. Defaults to runtime."New value: +"Where the dependency goes, in THESE words: \"runtime\" for a dependencies entry, \"development\" for devDependencies. The manifest and CLI spellings (\"dev\", \"devDependencies\", \"--save-dev\", \"prod\") are mapped onto these and reported in input_adjustments." - changed
Input schema / properties / to_version / descriptionPrevious value: -"The version you intend to install: an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\"). Omit to evaluate the latest published version."New value: +"A STRING: the version you intend to install — an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\"). Quote it even when it looks numeric (\"19\", not 19). Omit to evaluate the latest published version."
- Changed
verify_dependency_change1 field changed- added
Input schema / properties / evaluation / descriptionAdded value: +"The verification_context object exactly as evaluate_dependency_change returned it, passed back unchanged. Its signature covers every field, so edit nothing inside it. Sending the whole evaluate result instead is accepted; the receipt is read out of its verification_context."
1 tool update
- Changed
evaluate_dependency_change14 fields changed- changed
Input schema / additionalPropertiesPrevious value: -trueNew value: +false - changed
Input schema / examplesPrevious value: -[ - { - "change": { - "name": "lodash", - "to_version": "latest" - } - }, - { - "change": { - "from_version": "4.18.2", - "name": "express", - "to_version": "^5.0.0" - } - }, - { - "change": { - "dependency_type": "runtime", - "name": "zod", - "to_version": "3.23.8" - }, - "policy_profile": "strict", - "project": { - "direct_dependencies": { - "zod": "^3.22.0" - }, - "installed_versions": { - "zod": "3.22.4" - }, - "node_version": "20.11.0", - "package_manager": "pnpm", - "scripts": [ - "build", - "test" - ] - } - } -]New value: +[ + { + "dependency": "lodash", + "to_version": "4.17.21" + }, + { + "dependency": "express", + "from_version": "4.18.2", + "to_version": "^5.0.0" + }, + { + "dependency": "zod", + "policy_profile": "strict", + "project": { + "direct_dependencies": { + "zod": "^3.22.0" + }, + "installed_versions": { + "zod": "3.22.4" + }, + "node_version": "20.11.0", + "package_manager": "pnpm", + "scripts": [ + "build", + "test" + ] + }, + "to_version": "3.23.8" + } +] - removed
Input schema / properties / changeRemoved value: -{ - "additionalProperties": true, - "description": "The single dependency you are about to add or upgrade. One dependency per call.", - "properties": { - "dependency_type": { - "default": "runtime", - "description": "Where the dependency goes. Defaults to runtime.", - "enum": [ - "runtime", - "development", - "optional", - "peer" - ], - "type": "string" - }, - "ecosystem": { - "const": "npm", - "default": "npm", - "description": "Always npm. Omit it.", - "type": "string" - }, - "from_version": { - "description": "The version currently installed, or null / omitted when adding a new dependency. Supplying it is what produces a before/after advisory comparison. Alias keys \"current_version\", \"old_version\", \"previous_version\", and \"installed_version\" are adopted onto it.", - "maxLength": 128, - "type": [ - "string", - "null" - ] - }, - "name": { - "description": "The npm package name on its own — \"lodash\", \"@types/node\". Do NOT append a version here; a \"name@version\" spec is split for you and reported in input_adjustments. Alias keys \"package\", \"package_name\", \"pkg\", \"dep\", \"dependency\", \"dependency_name\", \"module\", \"library\", \"npm_package\", \"npm_package_name\", \"package_spec\", and \"dependency_spec\" are adopted onto it, as is any case or separator variant of \"name\".", - "maxLength": 214, - "minLength": 1, - "type": "string" - }, - "to_version": { - "description": "The version you intend to install: an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\", \"~1.2\", \"4.x\"). Omit it entirely to evaluate the latest published version, which is what plain `npm install <pkg>` would give you. Ranges and tags resolve to one exact version — read change.to_version in the response for the version the verdict actually covers. Alias keys \"version\", \"target_version\", \"new_version\", \"desired_version\", and \"requested_version\" are adopted onto it.", - "maxLength": 128, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "name" - ], - "type": "object" -} - added
Input schema / properties / dependencyAdded value: +{ + "description": "The npm package name on its own, with no version — \"lodash\", \"@types/node\".", + "maxLength": 214, + "minLength": 1, + "pattern": "^(@[^/\\s]+/)?[^@/\\s][^/\\s]*$", + "type": "string" +} - added
Input schema / properties / dependency_typeAdded value: +{ + "default": "runtime", + "description": "Where the dependency goes. Defaults to runtime.", + "enum": [ + "runtime", + "development", + "optional", + "peer" + ], + "type": "string" +} - added
Input schema / properties / from_versionAdded value: +{ + "description": "The version currently installed, or omitted when adding a new dependency. Supplying it produces a before/after advisory comparison.", + "maxLength": 128, + "type": [ + "string", + "null" + ] +} - changed
Input schema / properties / intent / descriptionPrevious value: -"Optional free text describing why you are making this change. Advisory only; it changes no verdict. Note this is a plain string here — plan_repo_task takes an object under the same name."New value: +"Optional free text describing why you are making this change. Advisory only; it changes no verdict." - added
Input schema / properties / package_managerAdded value: +{ + "description": "Optional. Only affects the commands and lockfile named in the verification plan. Inferred from project.lockfile_path when you send a project snapshot, and assumed to be npm otherwise.", + "enum": [ + "npm", + "pnpm", + "yarn", + "bun" + ], + "type": "string" +} - changed
Input schema / properties / policy_profile / descriptionPrevious value: -"Named team dependency policy. Strict requires provenance and denies package install hooks. This is the one key that must be spelled exactly — a near-miss spelling is rejected rather than guessed, because reading it wrong would answer under a policy you did not ask for."New value: +"Named team dependency policy. Strict requires provenance and denies package install hooks. Must be spelled exactly — a near-miss spelling is rejected rather than guessed, because reading it wrong would answer under a policy you did not ask for." - changed
Input schema / properties / project / additionalPropertiesPrevious value: -trueNew value: +false - changed
Input schema / properties / project / descriptionPrevious value: -"Optional, source-free facts about the project you are changing. Supplying it adds Node/peer/license compatibility and a command-level verification plan. Omit it entirely and compatibility comes back \"unknown\" — read that as not checked, never as no problem found. If you DO send it, package_manager is the one field you must include: it selects the lockfile and the commands in the verification plan, so guessing it would hand you instructions for the wrong repository. Every other field is optional and any that are missing are defaulted and reported, not rejected. Never send source code."New value: +"Optional, source-free facts about the project you are changing. Supplying it adds Node/peer/license compatibility and a command-level verification plan. Omit it entirely and compatibility comes back \"unknown\" - read that as not checked, never as no problem found. Every field is optional; anything missing is defaulted and reported in input_adjustments, never rejected. Never send source code." - removed
Input schema / properties / project / requiredRemoved value: -[ - "package_manager" -] - added
Input schema / properties / to_versionAdded value: +{ + "description": "The version you intend to install: an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\"). Omit to evaluate the latest published version.", + "maxLength": 128, + "minLength": 1, + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "change" -]New value: +[ + "dependency" +]
5 tool updates
- Changed
analyze_repo1 field changed- changed
Input schema / properties / package / descriptionPrevious value: -"npm package name, for example lodash or npm:@scope/pkg."New value: +"npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead."
- Changed
check_dependency1 field changed- changed
Input schema / properties / package / descriptionPrevious value: -"npm package name, for example lodash or npm:@scope/pkg."New value: +"npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead."
- Changed
evaluate_dependency_change13 fields changed- added
Input schema / examplesAdded value: +[ + { + "change": { + "name": "lodash", + "to_version": "latest" + } + }, + { + "change": { + "from_version": "4.18.2", + "name": "express", + "to_version": "^5.0.0" + } + }, + { + "change": { + "dependency_type": "runtime", + "name": "zod", + "to_version": "3.23.8" + }, + "policy_profile": "strict", + "project": { + "direct_dependencies": { + "zod": "^3.22.0" + }, + "installed_versions": { + "zod": "3.22.4" + }, + "node_version": "20.11.0", + "package_manager": "pnpm", + "scripts": [ + "build", + "test" + ] + } + } +] - added
Input schema / properties / change / descriptionAdded value: +"The single dependency you are about to add or upgrade. One dependency per call." - added
Input schema / properties / change / properties / dependency_type / descriptionAdded value: +"Where the dependency goes. Defaults to runtime." - added
Input schema / properties / change / properties / ecosystem / descriptionAdded value: +"Always npm. Omit it." - changed
Input schema / properties / change / properties / from_version / descriptionPrevious value: -"Version being upgraded from, or null when adding a new dependency. Omit to infer it from the project snapshot. Alias keys \"current_version\", \"old_version\", \"previous_version\", and \"installed_version\" are adopted onto it."New value: +"The version currently installed, or null / omitted when adding a new dependency. Supplying it is what produces a before/after advisory comparison. Alias keys \"current_version\", \"old_version\", \"previous_version\", and \"installed_version\" are adopted onto it." - changed
Input schema / properties / change / properties / name / descriptionPrevious value: -"npm package name. Prefer this key; the alias keys \"package\", \"package_name\", \"pkg\", \"dependency\", \"dependency_name\", \"module\", and \"library\" are adopted onto it and reported in input_adjustments."New value: +"The npm package name on its own — \"lodash\", \"@types/node\". Do NOT append a version here; a \"name@version\" spec is split for you and reported in input_adjustments. Alias keys \"package\", \"package_name\", \"pkg\", \"dep\", \"dependency\", \"dependency_name\", \"module\", \"library\", \"npm_package\", \"npm_package_name\", \"package_spec\", and \"dependency_spec\" are adopted onto it, as is any case or separator variant of \"name\"." - changed
Input schema / properties / change / properties / to_version / descriptionPrevious value: -"Target version. Accepts an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\", \"~1.2\", \"4.x\"). Tags and ranges are resolved to the single highest published match, which is what gets evaluated and reported back in input_adjustments. Alias keys \"version\", \"target_version\", and \"new_version\" are adopted onto it."New value: +"The version you intend to install: an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\", \"~1.2\", \"4.x\"). Omit it entirely to evaluate the latest published version, which is what plain `npm install <pkg>` would give you. Ranges and tags resolve to one exact version — read change.to_version in the response for the version the verdict actually covers. Alias keys \"version\", \"target_version\", \"new_version\", \"desired_version\", and \"requested_version\" are adopted onto it." - changed
Input schema / properties / change / requiredPrevious value: -[ - "name", - "to_version" -]New value: +[ + "name" +] - added
Input schema / properties / intent / descriptionAdded value: +"Optional free text describing why you are making this change. Advisory only; it changes no verdict. Note this is a plain string here — plan_repo_task takes an object under the same name." - changed
Input schema / properties / policy_profile / descriptionPrevious value: -"Named team dependency policy. Strict requires provenance and denies npm install hooks."New value: +"Named team dependency policy. Strict requires provenance and denies package install hooks. This is the one key that must be spelled exactly — a near-miss spelling is rejected rather than guessed, because reading it wrong would answer under a policy you did not ask for." - changed
Input schema / properties / project / additionalPropertiesPrevious value: -falseNew value: +true - added
Input schema / properties / project / descriptionAdded value: +"Optional, source-free facts about the project you are changing. Supplying it adds Node/peer/license compatibility and a command-level verification plan. Omit it entirely and compatibility comes back \"unknown\" — read that as not checked, never as no problem found. If you DO send it, package_manager is the one field you must include: it selects the lockfile and the commands in the verification plan, so guessing it would hand you instructions for the wrong repository. Every other field is optional and any that are missing are defaulted and reported, not rejected. Never send source code." - changed
Input schema / properties / project / requiredPrevious value: -[ - "package_manager", - "direct_dependencies" -]New value: +[ + "package_manager" +]
- Changed
get_artifact1 field changed- changed
Input schema / properties / package / descriptionPrevious value: -"npm package name, for example lodash or npm:@scope/pkg."New value: +"npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead."
- Changed
plan_repo_task1 field changed- changed
Input schema / properties / package / descriptionPrevious value: -"npm package name, for example lodash or npm:@scope/pkg."New value: +"npm package name, for example lodash or npm:@scope/pkg. To judge a specific VERSION rather than the package as a whole, use evaluate_dependency_change instead."
1 tool update
- Changed
evaluate_dependency_change3 fields changed- changed
Input schema / properties / change / properties / from_version / descriptionPrevious value: -"Version being upgraded from, or null when adding a new dependency. Omit to infer it from the project snapshot."New value: +"Version being upgraded from, or null when adding a new dependency. Omit to infer it from the project snapshot. Alias keys \"current_version\", \"old_version\", \"previous_version\", and \"installed_version\" are adopted onto it." - added
Input schema / properties / change / properties / name / descriptionAdded value: +"npm package name. Prefer this key; the alias keys \"package\", \"package_name\", \"pkg\", \"dependency\", \"dependency_name\", \"module\", and \"library\" are adopted onto it and reported in input_adjustments." - changed
Input schema / properties / change / properties / to_version / descriptionPrevious value: -"Target version. Accepts an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\", \"~1.2\", \"4.x\"). Tags and ranges are resolved to the single highest published match, which is what gets evaluated and reported back in input_adjustments."New value: +"Target version. Accepts an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\", \"~1.2\", \"4.x\"). Tags and ranges are resolved to the single highest published match, which is what gets evaluated and reported back in input_adjustments. Alias keys \"version\", \"target_version\", and \"new_version\" are adopted onto it."
2 tool updates
- Changed
evaluate_dependency_change1 field changed- changed
Input schema / requiredPrevious value: -[ - "change", - "project" -]New value: +[ + "change" +]
- Changed
verify_dependency_change1 field changed- added
Input schema / properties / evaluation / properties / baseline_project_snapshotAdded value: +{ + "const": "not_supplied", + "description": "Present only when the evaluation was made without a project snapshot. Part of the signed identity — pass it back verbatim.", + "type": "string" +}
1 tool update
- Changed
evaluate_dependency_change7 fields changed- changed
Input schema / additionalPropertiesPrevious value: -falseNew value: +true - changed
Input schema / properties / change / additionalPropertiesPrevious value: -falseNew value: +true - added
Input schema / properties / change / properties / dependency_type / defaultAdded value: +"runtime" - added
Input schema / properties / change / properties / ecosystem / defaultAdded value: +"npm" - added
Input schema / properties / change / properties / from_version / descriptionAdded value: +"Version being upgraded from, or null when adding a new dependency. Omit to infer it from the project snapshot." - added
Input schema / properties / change / properties / to_version / descriptionAdded value: +"Target version. Accepts an exact version (\"4.18.1\"), a dist-tag (\"latest\"), or a SemVer range (\"^4.17.0\", \"~1.2\", \"4.x\"). Tags and ranges are resolved to the single highest published match, which is what gets evaluated and reported back in input_adjustments." - changed
Input schema / properties / change / requiredPrevious value: -[ - "ecosystem", - "name", - "from_version", - "to_version", - "dependency_type" -]New value: +[ + "name", + "to_version" +]
4 tool updates
- Changed
check_change_risk6 fields changed- changed
Input schema / oneOfPrevious value: -[ - { - "not": { - "required": [ - "pr" - ] - }, - "required": [ - "diff" - ] - }, - { - "not": { - "required": [ - "diff" - ] - }, - "required": [ - "repo", - "pr" - ] - } -]New value: +[ + { + "not": { + "anyOf": [ + { + "required": [ + "pr" + ] + }, + { + "required": [ + "files" + ] + } + ] + }, + "required": [ + "diff" + ] + }, + { + "not": { + "anyOf": [ + { + "required": [ + "diff" + ] + }, + { + "required": [ + "files" + ] + } + ] + }, + "required": [ + "repo", + "pr" + ] + }, + { + "not": { + "anyOf": [ + { + "required": [ + "diff" + ] + }, + { + "required": [ + "pr" + ] + } + ] + }, + "required": [ + "files" + ] + } +] - added
Input schema / properties / base_shaAdded value: +{ + "pattern": "^[a-fA-F0-9]{40}$", + "type": "string" +} - added
Input schema / properties / contract_idAdded value: +{ + "description": "Optional short-lived contract_id returned by plan_repo_task.", + "pattern": "^[a-fA-F0-9]{32}$", + "type": "string" +} - added
Input schema / properties / filesAdded value: +{ + "description": "Privacy-preserving changed-file facts; contains no source or diff hunks.", + "items": { + "additionalProperties": false, + "properties": { + "additions": { + "maximum": 1000000, + "minimum": 0, + "type": "integer" + }, + "deletions": { + "maximum": 1000000, + "minimum": 0, + "type": "integer" + }, + "line_counts_known": { + "description": "False when Git could not provide text line counts; zeroes are then placeholders, not measured size.", + "type": "boolean" + }, + "path": { + "maxLength": 512, + "minLength": 1, + "type": "string" + }, + "previousPath": { + "maxLength": 512, + "minLength": 1, + "type": "string" + }, + "status": { + "enum": [ + "added", + "modified", + "removed", + "renamed", + "copied", + "changed" + ], + "type": "string" + } + }, + "required": [ + "path", + "additions", + "deletions", + "status" + ], + "type": "object" + }, + "maxItems": 250, + "minItems": 1, + "type": "array" +} - added
Input schema / properties / head_shaAdded value: +{ + "pattern": "^[a-fA-F0-9]{40}$", + "type": "string" +} - added
Input schema / properties / proofsAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "duration_ms": { + "maximum": 86400000, + "minimum": 0, + "type": "integer" + }, + "obligation_id": { + "maxLength": 80, + "minLength": 1, + "type": "string" + }, + "source": { + "enum": [ + "client_reported", + "github_check" + ], + "type": "string" + }, + "status": { + "enum": [ + "passed", + "failed", + "skipped" + ], + "type": "string" + } + }, + "required": [ + "obligation_id", + "status", + "source" + ], + "type": "object" + }, + "maxItems": 20, + "type": "array" +}
- Added
evaluate_dependency_change - Added
plan_repo_task - Added
verify_dependency_change
5 tool updates
- First observed
analyze_repo - First observed
check_change_risk - First observed
check_dependency - First observed
compare_repos - First observed
get_artifact
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
1A collaborative repository where AI agents and humans share research, images, videos and papers.
Evidence observatory for agentic commerce: x402 preflight, receipt checks, settlement attestations.
3
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI coding agents and hosts to enforce deterministic repository boundaries via MCP, providing structured reads, supervised edits, snapshots, audits, and recovery with machine-readable evidence.MIT
- AlicenseNot gradedqualityAmaintenanceLocal-first repository memory for AI coding agents that indexes codebases into SQLite and exposes it through MCP tools, with a browser dashboard for architecture inspection.19MIT
- AlicenseAqualityCmaintenanceEnables teams to share structured, git-synced context among AI coding agents working on the same repository, including living plans, task declarations, handoff briefs, file-provenance history, and conflict detection.121MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.3/5.0
Disambiguation3/5
The set separates into repo-orientation, dependency-checking, and change-risk workflows, but there is real overlap: analyze_repo/get_artifact/plan_repo_task all provide orientation and reading order, and check_dependency vs. evaluate_dependency_change both fire before adding/upgrading a dependency. The descriptions help clarify intent, yet an agent could still struggle to pick the right one in unfamiliar scenarios.
Naming Consistency5/5
Every tool follows a consistent verb_noun snake_case pattern: analyze_repo, check_dependency, compare_repos, evaluate_dependency_change, get_artifact, plan_repo_task, verify_dependency_change. The verbs are descriptive and the pattern makes the lifecycle stages predictable and easy to navigate.
Tool Count5/5
Eight tools is well within the ideal range for a server focused on repository and dependency due diligence. Each tool addresses a distinct phase of the workflow—orientation, planning, risk scoring, comparison, evaluation, and verification—without bloating the surface.
Completeness4/5
The server covers the core lifecycle well: understanding a repo, planning work, assessing change risk, evaluating dependencies, comparing options, and verifying updates. Minor gaps exist, such as no tool for auditing an entire dependency tree or comparing more than two candidates, but these are workable limitations rather than fatal omissions.