Skip to main content
Glama

Git.Top

by io.github.haocn-ops

get_project

Read-only

Return structured Git.Top knowledge for a project or collection, including the compact agent summary, overview, alternatives, deployments, quality score, agent score, project_kind, and collection_metadata when applicable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNoGitHub repository name, or owner/repo when owner is omitted.
ownerNoGitHub owner; use with repo when project_id is omitted.
projectNoAlias for project_id; accepts a canonical owner/repo identifier or Git.Top product alias.
project_idNoCanonical owner/repo identifier or a Git.Top product alias such as claude-code or cursor. The repo field may also contain owner/repo.
require_d1NoFail closed unless the tool result is backed by D1 instead of seed fallback.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Alias for project_id; accepts a canonical owner/repo identifier or Git.Top product alias.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.2/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 safety is covered. The description adds meaningful behavioral context by listing the exact content returned (agent summary, alternatives, deployments, quality score, etc.), which goes beyond the annotations.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the main action and resource, then lists the key return categories. Every word contributes meaning without unnecessary repetition.

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

Completeness4/5

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

For a read-only lookup tool with a comprehensive schema and rich annotations, the description sufficiently covers what the tool returns and the main resource types. A minor gap is not explicitly stating the return format (e.g., JSON) or failure behavior, but these are not critical given the tool's simplicity.

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 100%, so the schema fully documents parameters. The description adds value by clarifying that the tool returns structured project knowledge, which helps understand the purpose of the reference parameters, even though parameter details are not individually elaborated.

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

Purpose5/5

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

The description uses a specific verb ('Return') and a specific resource ('structured Git.Top knowledge for a project or collection'), enumerating the contained data fields. This clearly differentiates it from sibling tools like search_projects or compare_projects.

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

Usage Guidelines3/5

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

The description implies usage for retrieving comprehensive project knowledge, but it does not explicitly state when to prefer this tool over alternatives such as search_projects or recommend_project. No exclusions or conditions are provided.

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

All Git.Top 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

A3.9/5.0
Disambiguation5/5

Each tool addresses a distinct stage of the workflow: search_projects finds candidates, get_project retrieves detailed knowledge, recommend_project provides tailored suggestions, compare_projects contrasts options, and get_agent_workflow guides the overall process. No two tools have overlapping purposes, making misselection very unlikely.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (compare_projects, get_agent_workflow, get_project, recommend_project, search_projects). The two 'get_' tools are clearly differentiated by their objects (agent_workflow vs project), maintaining uniform style and predictability.

Tool Count5/5

Five tools is well within the ideal 3-15 range and perfectly scoped for a project discovery and comparison server. Each tool earns its place, covering search, retrieval, recommendation, comparison, and workflow guidance without redundancy or bloat.

Completeness5/5

The tool set covers the full user journey: discovering projects via search, getting in-depth information via get_project, obtaining personalized recommendations, comparing alternatives, and following a structured analysis workflow. No obvious gaps exist for the platform's stated purpose.

Resources