Which integrations are available for this server?

Provides tools for fetching Figma file/frame metadata, exporting frame images, generating design handoff packages, and running Figma Make handoff orchestration using the official Figma REST API and Figma MCP. Provides tools for git status, diffs, readiness checks, safety scans, staging, committing, and pushing changes within allowed repositories.

How do I use ChampCity GPT MCP Launcher?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ChampCity GPT MCP Launcher list files in my project root" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ChampCity GPT MCP Launcher

by ChampCityChris

Overview Schema Related Servers Score Discussions

TypeScript

Local

ChampCity GPT MCP Launcher

ChampCity GPT MCP Launcher is a pre-release ChatGPT-compatible MCP server and Electron launcher for controlled local project-file access. It can expose read-only and approval-gated write tools over local STDIO or local HTTP, with optional OAuth and HTTPS tunneling for ChatGPT.com-compatible MCP connectors.

Current maturity: v0.1.2, pre-release/private-tooling quality. Review the code and security model before using it with sensitive repositories.

License: not yet selected. See docs/LICENSE_DECISION_NEEDED.md.

What It Does

Lists, reads, and searches files inside configured allowed roots.
Reports git status and git diffs for allowed git worktrees.
Provides safe git workflow tools for readiness checks, safety scans, filtered staging, validated local commits, and optional non-force pushes.
Contains experimental/deferred Figma-to-Codex design handoff tools using the official Figma REST API for Design URLs and official Figma MCP resources for Make URLs.
Supports write modes: off, docs, patch, and elevated.
Provides an Electron launcher for local setup, status checks, OAuth administration, and client config generation.
Supports local STDIO MCP for trusted local clients.
Runs the local Streamable HTTP MCP server inside the packaged Electron app on 127.0.0.1.
Supports OAuth metadata, Dynamic Client Registration, PKCE, access tokens, refresh token rotation, and scopes for ChatGPT.com-compatible public HTTPS endpoints.
Includes optional Cloudflare Tunnel docs and examples.

Related MCP server: BridgeDesk

What It Does Not Do

It does not make hosted ChatGPT local-only; file contents returned by tools can enter the model/tool context.
It does not safely expose arbitrary folders. You must configure narrow allowed roots.
It does not require Cloudflare or any specific domain. https://mcp.example.com/mcp is only a placeholder.
It does not enable writes by default.
It does not commit or expose Figma tokens, auth headers, cookies, or session credentials. Generated Design handoffs may still contain private screenshots or metadata; generated Make handoffs may contain private source/resources.
It does not replace human review. Review generated patches and git diffs before committing.

Security Model

Filesystem access is limited to configured allowed roots. Use project-level roots such as:

C:\Users\<you>\Projects\<project>

Avoid broad roots such as C:\, C:\Users\<you>, home directories, cloud sync roots, browser profile folders, SSH folders, and credential stores.

HTTP mode should bind to 127.0.0.1 by default. ChatGPT.com compatibility requires an HTTPS-reachable endpoint with OAuth and Dynamic Client Registration. For public use, set:

CHAMPCITY_GPT_PUBLIC_BASE_URL=https://mcp.example.com

OAuth scopes:

files.read: list/read/search files, git status/diff, write-access status, Figma status/URL parsing/file summaries, commit readiness, safety scans, and tool discovery.
files.write: propose patches, write Markdown artifacts, apply approved patches, export Figma frame images, create Figma handoff packages, run Figma Make handoff orchestration, create Codex UI handoff prompts, run allowlisted scripts, safely stage files, create validated commits, and optionally push, still gated by local write mode.

Never expose unauthenticated HTTP mode through a tunnel.

Write Modes

off: default. Blocks write tools.
docs: allows Markdown artifact writes for planning or notes.
patch: allows proposed patch workflows and approved patch application.
elevated: allows rare allowlisted script/elevated operations and safe git stage/commit/push workflows.

Set the mode with:

$env:CHAMPCITY_GPT_WRITE_MODE='off'

Local Configuration

On first launch, the Electron app opens a setup wizard where each user chooses allowed roots, local-only or public endpoint mode, OAuth admin password, optional Cloudflare guidance, and write mode. Write mode defaults to off, and the OAuth admin password is stored only as a local hash.

Packaged App Runtime

End users do not need Node.js, npm, PowerShell server startup, a source checkout, or npm install to run the packaged app. The installed or portable executable starts the HTTP MCP server in-process from bundled Electron modules when the user clicks Start Local HTTP MCP Server.

Node.js and npm are developer prerequisites only for building from source, running tests, or using the advanced CLI server entrypoint.

The developer CLI remains available after a source build:

node dist\src\index.js --transport stdio
node dist\src\index.js --transport http --host 127.0.0.1 --port 3333

For source development, you can still copy example config files and create repo-local versions as needed:

Copy-Item config\allowed-roots.example.json config\allowed-roots.local.json
Copy-Item config\write-access.example.json config\write-access.local.json

Local files matching config/*.local.json are ignored by git. Do not commit OAuth stores, auth tokens, local paths, tunnel credentials, logs, generated configs, release outputs, or .env files.

Figma Design Handoff

v1.0 scope note: Figma tools are deferred from v1.0 production-core scope. The current Figma workflow must be revisited before it can be treated as a supported product feature. v1.0 remains focused on ChatGPT-to-local-repository access, connector reliability, source-control/release automation, guided setup, and public-user distribution.

ChampCity GPT can fetch Figma file/frame metadata through the official Figma REST API and generate a Codex-ready UI implementation handoff. Configure a Figma personal access token locally:

Copy-Item config\figma.example.json config\figma.local.json

Then edit config\figma.local.json:

{
  "figmaAccessToken": "<FIGMA_ACCESS_TOKEN>"
}

CHAMPCITY_GPT_FIGMA_ACCESS_TOKEN overrides the local file. Installed mode stores the local file under the app userData config directory; portable mode stores it under data\config; development mode can use repo-local config\figma.local.json. The launcher can save or clear the local token, but never displays it after save. If the token comes from the environment, clear it outside the app.

Figma tools:

get_figma_status: reports configured yes/no and source without the token.
parse_figma_url: parses /design, /file, and /proto URLs.
fetch_figma_file_summary: returns compact file/frame/component/style metadata.
fetch_figma_frame_image: writes one PNG/SVG export inside an allowed root.
create_figma_handoff_package: writes design/figma-handoff by default.
create_codex_ui_handoff_prompt: writes docs/handoffs/CODEX_UI_REDESIGN_HANDOFF.md by default.
test_figma_mcp_connection: probes the configured upstream Figma MCP server without exposing credentials.
run_figma_make_handoff: accepts a /make/ URL, retrieves Make resources through the configured official Figma MCP server, writes design/figma-handoff/make and docs/handoffs/CODEX_FIGMA_MAKE_UI_HANDOFF.md by default, and returns paths plus warnings without exposing credentials.

Default handoff package:

design/figma-handoff/
  README_DESIGN_HANDOFF.md
  figma-link.txt
  specs/
    screen-map.md
    component-inventory.md
    interaction-notes.md
    implementation-notes.md
    acceptance-criteria.md
  tokens/
    design-tokens.json
  screenshots/
  assets/

Figma image export and Design handoff generation require OAuth files.write for HTTP callers and local write mode docs, patch, or elevated. Figma Make URLs use the dedicated run_figma_make_handoff path, are not sent through the Design REST parser, and require an upstream official Figma MCP server such as the desktop endpoint http://127.0.0.1:3845/mcp or a configured remote HTTPS endpoint. Make handoff success requires actual MCP resources/files under design/figma-handoff/make/source; screenshots are intentionally not generated for Make MCP resource handoffs.

Recommended Git Workflow

Use dev or a feature branch for normal work. main commits and pushes are refused by default unless the caller explicitly opts in.

Validate locally with npm run build, npm test, npm run typecheck, npm run lint, and npm run check:public.
Ask ChatGPT to run get_commit_readiness.
Ask ChatGPT to run safe_stage_changes for all safe files or reviewed paths.
Ask ChatGPT to run pre_commit_safety_scan.
Ask ChatGPT to run commit_validated_changes with a reviewed commit message.
Ask ChatGPT to run push_current_branch only after reviewing the commit result.

The staging tool never stages local config, logs, generated output, release artifacts, dist, node_modules, .env, ignored files, or files with blocker secret/private-path findings. Push is optional and never uses force flags. Releases are separate from commits; release binaries belong in GitHub Releases, not in the repository.

Useful examples:

Development

Build-from-source requirements:

Node.js >=20.10.0
npm

Install, build, and test:

npm install
npm run build
npm test
npm run typecheck
npm run lint

Public clone/build flow:

git clone https://github.com/<owner>/<repo>.git
cd <repo>
npm install
npm run build
npm test
npm run app:dist

Run the local MCP server after building:

node dist\src\index.js

Run the Electron app:

npm run app:dev

Package the Electron app:

npm run app:dist

Release binaries belong in GitHub Releases, not in the repository.

Runtime Paths

Development mode uses the source checkout and can use repo-local config/*.local.json for development.

Installed mode stores runtime-local files under Electron userData:

config
logs
generated

Portable mode activates when a data folder exists next to the executable:

<exeDir>\data\config
<exeDir>\data\logs
<exeDir>\data\generated

The app status panel shows runtime mode, server runtime, config directory, logs directory, generated directory, public base URL, write mode, OAuth status, and developer CLI paths when relevant.

ChatGPT-Compatible HTTPS Endpoint

For ChatGPT.com-compatible MCP registration, use an HTTPS endpoint like:

https://mcp.example.com/mcp

The server exposes OAuth metadata under:

https://mcp.example.com/.well-known/oauth-protected-resource
https://mcp.example.com/.well-known/oauth-authorization-server
https://mcp.example.com/oauth/register
https://mcp.example.com/oauth/authorize
https://mcp.example.com/oauth/token

Cloudflare Tunnel is optional. Any equivalent HTTPS reverse tunnel can work if OAuth remains enabled and the local service is still bound narrowly.

Publication Safety

Before publishing, run the release and publication checklists:

Do not publish until the license, GitHub owner/repo, and release-binary policy are decided.

Final local checks:

npm run check:public
npm run app:dist
npm run check:release

Available Tools

19 tools

fetch_figma_file_summaryC

Fetch a Figma file with the locally configured Figma token and return only a compact metadata summary. Requires OAuth files.read for HTTP callers.

ParametersJSON Schema

Name	Required	Description	Default
`fileKey`	Yes
`maxFrames`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It states it returns a 'compact metadata summary' and requires a token/OAuth, but omits details on side effects (likely read-only), rate limits, or what the summary includes. More behavioral context is needed for a tool with zero 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?

Two sentences, no redundancy, front-loaded with essential purpose. Every word adds value. Perfectly concise.

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

Completeness2/5

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

Given 2 parameters and no output schema, the description should explain what the metadata summary contains and how maxFrames influences the result. Without this, the tool is incomplete for correct invocation and interpretation.

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

Parameters1/5

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

Schema has 2 parameters (fileKey, maxFrames) with 0% description coverage. The description does not explain either parameter or how they affect behavior. 'Compact metadata summary' does not clarify the role of maxFrames, leaving agents without semantic understanding.

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

Purpose5/5

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

The description clearly states the action (Fetch), resource (Figma file), and scope (compact metadata summary). It also mentions authentication requirements (locally configured token, OAuth files.read). This distinguishes it from sibling tools like get_figma_status or parse_figma_url.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives like get_figma_status or parse_figma_url. It mentions OAuth requirements but no context on when not to use or which sibling is better suited.

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

get_builder_report_indexA

Read-only. Returns a bounded Builder Report index for configured workspaces. Does not modify repository files, git state, release state, or configuration.

ParametersJSON Schema

Name	Required	Description	Default
`maxResults`	No
`workCardId`	No
`phaseFolder`	No
`workspaceId`	No

TDQS

A3.7/5.0

Behavior4/5

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

The description explicitly states the tool is read-only and does not modify repository files, git state, release state, or configuration. This provides clear behavioral expectations. With no annotations present, the description adequately covers safety and side-effect transparency.

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 exceptionally concise with two sentences that each serve a purpose: first states functionality, second clarifies non-destructive nature. No extraneous information is present.

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

Completeness2/5

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

Despite the tool having 4 optional parameters and no output schema, the description does not explain the return value format, the meaning of 'bounded index', or how parameters affect the result. Given the complexity, the description is incomplete for an agent to effectively use the tool without additional guidance.

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

Parameters2/5

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

The input schema has 4 optional parameters with 0% description coverage, and the description adds no detail about parameter meanings, formats, or constraints. The tool name and description hint at 'workspaceId' but do not elaborate on 'maxResults', 'workCardId', or 'phaseFolder', leaving the agent to guess their purpose.

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 is read-only and returns a bounded Builder Report index for configured workspaces. It also explicitly lists what it does not modify, making the purpose specific and distinct from sibling tools which cover different summaries and statuses.

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

Usage Guidelines3/5

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

The description implies use when needing a bounded Builder Report index for configured workspaces, but does not explicitly instruct when to use or not use this tool over alternatives like get_builder_report_summary. The sibling tools list suggests differentiation, but no direct comparison is provided.

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

get_builder_report_summaryB

Read-only. Returns a bounded Builder Report preview from a safe report lookup. Does not modify repository files, git state, release state, or configuration.

ParametersJSON Schema

Name	Required	Description	Default
`maxChars`	No
`reportPath`	No
`workCardId`	No
`phaseFolder`	No
`workspaceId`	No

TDQS

B3.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It explicitly states 'Read-only' and lists systems not modified (repository files, git state, release state, configuration), providing valuable safety assurances beyond the tool's name.

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

Conciseness4/5

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

The description is concise with two clear sentences. It efficiently communicates the tool's nature and safety profile, though it could be improved by briefly noting parameter dependencies without becoming verbose.

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

Completeness2/5

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

The description is incomplete given the context: five optional parameters with no guidance, no output schema, and 0% schema coverage. It does not explain how to specify a report or what the summary contains, leaving the agent with insufficient information to use the tool correctly.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no information about the five parameters (maxChars, reportPath, workCardId, phaseFolder, workspaceId). The agent cannot infer which parameters are needed or how they affect the result.

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

Purpose4/5

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

The description clearly states it returns a 'bounded Builder Report preview' from a 'safe report lookup', identifying the resource and action. However, it does not explain what a Builder Report is or what the preview contains, leaving some ambiguity.

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 a report summary without modification, but lacks explicit guidance on when to use this tool over siblings like get_builder_report_index or get_change_set_readiness_summary.

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

get_change_set_readiness_summaryC

Read-only. Returns a sanitized change set readiness summary for the configured workspace. Does not modify repository files, git state, release state, or configuration.

ParametersJSON Schema

Name	Required	Description	Default
`workspaceId`	No
`targetBranch`	No

TDQS

C2.9/5.0

Behavior3/5

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

States it does not modify files or state, but no annotations provided. Lacks details on required permissions, rate limits, or what the summary includes.

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

Conciseness5/5

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

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

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

Completeness2/5

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

No output schema, and description does not explain what the summary contains or how to interpret it. Missing context for effective use.

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

Parameters1/5

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

Schema has 0% description coverage, and the description does not mention the parameters (workspaceId, targetBranch) at all, leaving their purpose unclear.

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?

Description clearly states it returns a sanitized change set readiness summary and is read-only. However, it does not explicitly differentiate from sibling tools like get_commit_readiness or get_workspace_status_summary.

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

Usage Guidelines2/5

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

Only says 'Read-only', which hints at non-destructive use, but no explicit guidance on when to use this tool versus alternatives or any prerequisites.

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

get_commit_readinessC

Return read-only commit/push readiness status.

ParametersJSON Schema

Name	Required	Description	Default
`root`	Yes	Absolute configured allowed root.
`targetBranch`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations exist, so the description carries the full burden. It mentions 'read-only' which is helpful, but does not disclose other behavioral traits such as network calls, permissions, or side effects. The description is too sparse.

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

Conciseness4/5

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

One short sentence, front-loaded with the core purpose. No wasted words. However, it may be too concise, sacrificing clarity for brevity.

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

Completeness2/5

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

With no output schema, minimal parameter descriptions, and no usage context, the description is incomplete. An agent cannot determine the return format, the meaning of 'status', or how to interpret 'root'. More detail is needed.

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

Parameters2/5

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

Schema description coverage is 50% (root described, targetBranch not). The description adds no additional meaning beyond the schema. For targetBranch, the enum provides context, but the description does not explain its purpose relative to the tool.

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

Purpose4/5

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

The description clearly states the tool returns a read-only commit/push readiness status. It distinguishes from siblings like git_diff or get_change_set_readiness_summary by focusing on commit readiness. However, it could be more specific about what the status encompasses.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description only states what it does, leaving the agent to infer context.

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

get_figma_statusA

Return whether a local Figma token is configured and its source without exposing the token value.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

Description explicitly states the tool does not expose the token value, which is a key behavioral constraint. However, it lacks details on error handling or behavior when token is missing, though for a simple check this is acceptable.

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?

Single sentence, front-loaded with the primary action ('Return whether...'), no unnecessary words. Highly concise.

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 no parameters and no output schema, the description provides sufficient information for a simple status check. It could specify the return format (e.g., boolean and source string), but the current description is adequate.

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 has 0 parameters with 100% coverage, so baseline is 4. Description adds no parameter info, but none is needed.

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 returns whether a local Figma token is configured and its source, specifying a distinct verb and resource. It distinguishes from siblings like 'fetch_figma_file_summary' by focusing on token configuration status.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives (e.g., before calling other Figma tools). The context is implied but not stated.

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

get_release_artifact_summaryC

Read-only. Returns a sanitized release artifact summary for a requested version. Does not modify repository files, git state, release state, or configuration.

ParametersJSON Schema

Name	Required	Description	Default
`workspaceId`	No
`releaseVersion`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

Description explicitly declares read-only behavior and lists what it does not modify (repository files, git state, release state, configuration). However, it omits details on auth requirements, error handling, or what happens if the version is not found. With no annotations, the description partially but not fully compensates.

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

Conciseness5/5

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

Two concise sentences, no redundancy. All information is front-loaded and clearly stated.

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

Completeness2/5

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

Given the tool has two parameters with no descriptions and no output schema, the description is too minimal. It lacks information on parameter usage, return format, and error scenarios, leaving significant gaps for the agent.

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

Parameters1/5

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

Schema coverage is 0%, and the description provides no information about the parameters (workspaceId, releaseVersion). The agent must infer that releaseVersion is needed from the required field, but no format or constraints are given. WorkspaceId is not mentioned at all.

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?

Description clearly states the verb 'returns' and resource 'sanitized release artifact summary' for a requested version, and specifies it is read-only. However, it does not explicitly differentiate from sibling tools like get_release_publication_summary, relying on the name for distinction.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description only states what it does without providing context on preferred use cases or exclusion criteria.

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

get_release_publication_summaryB

Read-only. Returns a sanitized GitHub release publication summary for a requested tag. Does not modify repository files, git state, release state, or configuration.

ParametersJSON Schema

Name	Required	Description	Default
`tagName`	Yes
`workspaceId`	No
`includeAssets`	No

TDQS

B3.1/5.0

Behavior4/5

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

The description explicitly states the tool does not modify repository files, git state, release state, or configuration, providing good behavioral transparency. However, it does not mention authentication or rate limits, which are relevant for read-only tools.

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

Conciseness4/5

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

The description is concise with two sentences, front-loading 'Read-only'. However, it could benefit from brief parameter details without being verbose.

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

Completeness2/5

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

Given three parameters and no output schema, the description is incomplete. It omits explanations for workspaceId and includeAssets, and does not describe the return value structure beyond 'sanitized summary'.

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

Parameters2/5

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

Schema description coverage is 0%. The description only hints at tagName ('for a requested tag') but provides no explanation for optional parameters workspaceId and includeAssets. The agent must guess their purpose from names alone.

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

Purpose4/5

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

The description clearly states the tool is read-only and returns a sanitized GitHub release publication summary for a requested tag. It uses a specific verb and resource, but does not differentiate from sibling summary tools like get_release_artifact_summary.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It only mentions read-only behavior, but does not specify scenarios or exclusions relative to sibling tools.

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

get_workspace_status_summaryB

Read-only. Returns a sanitized summary of the configured workspace state. Does not modify repository files, git state, release state, or configuration.

ParametersJSON Schema

Name	Required	Description	Default
`workspaceId`	No

TDQS

B3.1/5.0

Behavior4/5

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

The description clearly states it is read-only and does not modify repository, git, release, or configuration state. Since no annotations are provided, the description alone carries this burden and does so effectively.

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 extremely concise with two sentences that front-load the core purpose and immediately address safety concerns. Every sentence earns its place with no waste.

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

Completeness2/5

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

Despite having no output schema and only one parameter, the description lacks detail about what the summary contains, how to interpret it, and how it differs from similar tools. The agent cannot fully judge invocation suitability.

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

Parameters1/5

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

The parameter workspaceId is not described at all. Schema coverage is 0%, and the description fails to explain its purpose, optionality, or default behavior, leaving the agent without necessary semantic information.

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 uses a specific verb 'get' and resource 'workspace status summary', and clarifies it returns a sanitized summary. It distinguishes minimally from sibling tools by emphasizing it does not modify files, but does not explicitly differentiate from other summary tools like get_builder_report_summary.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. It mentions read-only but does not provide context for when it is appropriate or what prerequisites exist.

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

get_write_access_statusA

Return the server-side write-mode status without exposing secrets.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It implicitly suggests the tool is safe (no secrets exposed) and is a read-only operation, but does not explicitly confirm no side effects, no destructive actions, or authentication requirements. The single behavioral trait is useful but incomplete.

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

Conciseness5/5

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

The description is a single sentence with no unnecessary words. It is front-loaded with the core purpose and adds a key constraint (without exposing secrets) efficiently. Every part earns its place.

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

Completeness4/5

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

Given zero parameters and a simple purpose, the description is reasonably complete. However, it lacks detail about what the status values might be (e.g., 'enabled', 'disabled') and does not mention potential errors or when the status might be unavailable, which would be helpful for an agent.

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?

There are zero parameters, so schema coverage is effectively 100%. The description adds no parameter information because none exists, but it appropriately implies no parameters are needed. The baseline of 4 is justified.

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 returns the server-side write-mode status and explicitly mentions it does not expose secrets, which is a specific and actionable verb-resource pair. It distinguishes itself from sibling tools like get_workspace_status_summary by focusing on write-mode specifically, though not naming alternatives.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or cases where another tool would be more appropriate. For a simple status check, some context about its role in workflows would be helpful.

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

git_diffC

Return git diff or git diff --staged for an allowed root with byte truncation.

ParametersJSON Schema

Name	Required	Description
`root`	Yes	Absolute configured allowed root.
`staged`	No
`maxBytes`	No

TDQS

C2.9/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions 'byte truncation' and 'allowed root,' hinting at behavioral traits. However, it does not disclose whether the tool is read-only, destructive, or has side effects, leaving gaps for the agent.

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

Conciseness4/5

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

The description is a single, front-loaded sentence that conveys the essential function without waste. However, it is slightly too brief, omitting important context.

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

Completeness2/5

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

Given three parameters, no output schema, and no annotations, the description is insufficient. It lacks explanation of maxBytes behavior, return value format, and edge cases, making it incomplete for an agent to fully understand the tool.

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

Parameters2/5

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

Schema description coverage is 33% (only root described). The description hints at 'staged' and 'byte truncation' (maxBytes) but adds no extra meaning beyond the schema. Parameters are not elaborated, leaving the agent to infer their purpose.

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

Purpose4/5

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

The description clearly states it returns git diff or git diff --staged for an allowed root with byte truncation. The verb 'Return' is specific, and the tool distinguishes from siblings like git_status. However, it could be more explicit about the resource being git diff for a particular root.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives (e.g., git_status or other sibling tools). There is no mention of prerequisites, scenarios, or exclusions.

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

git_statusB

Return git status --short and the current branch for an allowed root.

ParametersJSON Schema

Name	Required	Description	Default
`root`	Yes	Absolute configured allowed root.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It reveals that the tool performs a read operation (git status) but does not mention safety, error conditions, or permissions. The description is minimal and relies on the user's knowledge of git.

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

Conciseness5/5

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

The description is a single sentence that is concise and front-loaded with the action verb. Every word is necessary and contributes to the purpose.

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

Completeness3/5

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

For a simple one-parameter tool, the description covers the core functionality but omits details about the output format (e.g., whether it returns a string, the exact layout). It is adequate but not fully 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?

The input schema has 100% description coverage for the only parameter 'root', and the description repeats the concept of 'allowed root' without adding new detail. The description does not enhance understanding beyond the schema.

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

Purpose4/5

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

The description clearly states the tool returns git status --short and the current branch for an allowed root, using a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like git_diff, though the purpose is clear.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as git_diff or other status tools. There is no mention of context, prerequisites, 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.

list_project_filesC

List files under an allowed root or subdirectory without returning contents.

ParametersJSON Schema

Name	Required	Description
`glob`	No
`root`	Yes	Absolute configured allowed root.
`maxResults`	No
`relativePath`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only discloses that contents are not returned. It omits behavioral aspects like permissions needed, rate limits, error scenarios (e.g., invalid root), or whether listing is recursive.

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

Conciseness4/5

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

Description is a single, clear sentence with no wasted words. It is front-loaded with the key action and result. Slightly too brief but avoids redundancy.

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

Completeness2/5

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

Given 4 parameters and no output schema, the description is minimal. It does not explain how glob filtering works, maxResults limits, or the relationship between root and relativePath, leaving the agent with gaps for correct usage.

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

Parameters2/5

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

Schema description coverage is 25% (only root described). The tool description adds 'allowed root or subdirectory' hinting at root/relativePath but does not explain glob patterns or maxResults behavior. Scores low due to insufficient compensation for missing schema descriptions.

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

Purpose5/5

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

The description uses specific verb 'List' and resource 'files', clarifying the scope under 'allowed root or subdirectory' and distinguishing from siblings like read_project_file by stating 'without returning contents'. This clearly differentiates from similar tools.

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

Usage Guidelines2/5

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

No guidance on when to use this tool compared to alternatives like search_project_files or read_project_file. The description only states functionality, not context of use or exclusions.

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

parse_figma_urlA

Parse a Figma design/file/proto URL into fileKey, normalized nodeId, and urlType without calling Figma.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description partially carries the behavioral burden. It communicates that the tool is non-destructive and doesn't make external calls, but it does not disclose error handling for malformed URLs or outline any constraints on URL format.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no wasted words. It efficiently states the action, input, output, and key differentiator (no Figma call).

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

Completeness5/5

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

Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context: it specifies the input type, the extracted fields, and that it operates offline. No additional explanatory text is needed.

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 0%, but the description specifies the accepted URL types (Figma design/file/proto URL), adding some semantics. However, it does not provide full format details or examples, leaving room for ambiguity.

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 that it extracts fileKey, normalized nodeId, and urlType from a Figma URL, and notes that it does not call Figma, differentiating it from sibling tools that likely require API calls.

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 local usage (no API call) but does not specify when to use this tool over alternatives or exclude cases where URL is invalid. No sibling tool is named as an alternative for URL parsing.

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

pre_commit_safety_scanA

Run public-repo safety scans for staged files, working-tree changes, or selected paths without staging or committing anything.

ParametersJSON Schema

Name	Required	Description
`mode`	No
`root`	Yes	Absolute configured allowed root.
`paths`	No

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description only states that the tool is non-mutating. It does not explain what a 'safety scan' entails, what checks are performed, or what the output/return value looks like. More behavioral details are needed for a scan tool.

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?

A single, well-structured sentence that is front-loaded with the verb and efficiently conveys the core purpose. Every word earns its place.

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

Completeness3/5

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

For a tool with three parameters and no output schema, the description is adequate but lacks details on return values, prerequisites (e.g., repo setup), or what 'public-repo' implies. Additional context about the scan process would improve completeness.

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 low (33%). The description adds context by listing the three modes (staged, working-tree, paths) corresponding to the 'mode' enum, but does not elaborate on the 'paths' parameter or the meaning of 'root'. This provides moderate added value beyond the 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 clearly states the action ('Run public-repo safety scans'), specifies the resource ('staged files, working-tree changes, or selected paths'), and explicitly notes that it does not stage or commit. This distinguishes it from sibling tools like git_diff or git_status.

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 running safety scans without staging or committing, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools for actual staging or committing.

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

propose_patchA

Generate a unified diff without modifying files and register a short-lived patch proposal. The returned proposalId/patchHash can be used by apply_approved_patch in patch write mode.

ParametersJSON Schema

Name	Required	Description	Default
`root`	Yes	Absolute configured allowed root.
`changes`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

The description discloses that the tool does not modify files and that the proposal is short-lived. However, with no annotations, it lacks additional behavioral context such as authorization requirements, rate limits, or side effects beyond registration.

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, front-loaded with the core action, and every word serves a purpose. No redundancy.

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

Completeness2/5

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

Given the presence of required parameters and no output schema, the description is incomplete. It lacks parameter details and fails to provide sufficient context for an agent to decide when to use this tool effectively.

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

Parameters2/5

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

Schema coverage is 50%, but the description adds no explanation of parameters (root and changes) beyond what is in the schema. The description does not clarify what constitutes a valid root path or the expected format of changes items, leaving ambiguity.

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 generates a unified diff without modifying files and registers a short-lived patch proposal. It also specifies the output can be used by apply_approved_patch, providing a complete purpose and differentiating from sibling tools like git_diff.

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 by mentioning the return value is for apply_approved_patch, but it does not explicitly state when to use this tool vs. alternatives like git_diff or pre_commit_safety_scan. No exclusions or when-not-to-use guidance is provided.

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

read_project_fileC

Read a text file from an allowed root with path, file, binary, and size checks.

ParametersJSON Schema

Name	Required	Description
`root`	Yes	Absolute configured allowed root.
`maxBytes`	No
`relativePath`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided, so description must convey behavior. It mentions path, file, binary, and size checks but does not explain what happens on failure, binary rejection, or permissions. Vague on error handling.

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

Conciseness3/5

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

Single sentence is concise but at the expense of clarity. It could be expanded to provide necessary context without becoming verbose.

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

Completeness2/5

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

For a tool with 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return format, error behavior, or how to appropriately invoke the tool. Sibling tools like list_project_files suggest context but not covered.

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

Parameters2/5

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

The description adds minimal semantic value beyond schema. Only root is described as 'Absolute configured allowed root.' No explanation of relativePath format or maxBytes (e.g., truncation vs error). Schema coverage is low (33%), so description should compensate.

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

Purpose4/5

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

The description clearly states the tool reads a text file from an allowed root with specific checks, distinguishing it from listing or searching siblings. However, it does not explicitly differentiate from related tools like list_project_files or search_project_files.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. The description lacks context on proper invocation scenarios.

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

search_project_filesB

Search text files under an allowed root and return line-level matches with limited context.

ParametersJSON Schema

Name	Required	Description
`glob`	No
`root`	Yes	Absolute configured allowed root.
`query`	Yes
`maxResults`	No
`contextLines`	No

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only mentions 'limited context' without explaining constraints, error cases, or access requirements. Much behavior is undisclosed.

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

Conciseness4/5

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

The single sentence is efficient and front-loaded with the core action, though 'limited context' could be more specific.

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

Completeness2/5

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

For a tool with 5 parameters (2 required) and no output schema or annotations, the description is too sparse, providing insufficient guidance on parameters and return format.

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

Parameters2/5

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

Schema description coverage is low (20%), and the description adds no meaningful explanation beyond the schema for any of the 5 parameters, leaving glob, maxResults, contextLines unexplained.

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

Purpose5/5

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

The description clearly states the action (search), resource (text files under an allowed root), and result (line-level matches with limited context), effectively distinguishing it from siblings like list_project_files and read_project_file.

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 searching text files but provides no explicit guidance on when to use this tool versus alternatives or any exclusions.

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

test_figma_mcp_connectionA

Test the configured upstream Figma MCP server connection, list available MCP resources/templates/tools/prompts when reachable, and report whether Make resource retrieval appears available.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Optional override for upstream Figma MCP mode.
`endpoint`	No	Optional override for the upstream Figma MCP endpoint.

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description covers the main behavior: testing connection, listing resources, and reporting availability. It implies read-only intent and explicitly mentions 'when reachable', but does not detail error handling or side effects.

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

Conciseness5/5

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

The description is a single, information-dense sentence with no wasted words. It front-loads the primary action and covers multiple aspects efficiently.

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

Completeness4/5

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

Given the tool's simplicity (2 optional params, no output schema), the description adequately explains input, actions, and part of the output. It could mention return format or error cases, but is sufficient for basic understanding.

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%, with both parameters already described. The tool description adds no additional parameter semantics, so baseline score of 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's purpose: testing the Figma MCP connection, listing available resources, and reporting on Make resource availability. It distinguishes itself from sibling tools like fetch_figma_file_summary or get_figma_status as a general connectivity test.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives or when not to use it. The description only explains functionality, not usage context.

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.

19 tool updatesv0.1.2Jun 30, 2026
- First observedfetch_figma_file_summary
- First observedget_builder_report_index
- First observedget_builder_report_summary
- First observedget_change_set_readiness_summary
- First observedget_commit_readiness
- First observedget_figma_status
- First observedget_release_artifact_summary
- First observedget_release_publication_summary
- First observedget_workspace_status_summary
- First observedget_write_access_status
- First observedgit_diff
- First observedgit_status
- First observedlist_project_files
- First observedparse_figma_url
- First observedpre_commit_safety_scan
- First observedpropose_patch
- First observedread_project_file
- First observedsearch_project_files
- First observedtest_figma_mcp_connection

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool targets a distinct domain or action: Figma-related tools are clearly separate from git, file, and workspace/release status tools. Even within similar categories (e.g., multiple get_*_summary tools), each refers to a different entity (builder report, release artifact, etc.), so there is no ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as fetch_, get_, git_, list_, parse_, propose_, read_, search_, test_, and pre_commit_safety_scan. The style is uniform, making it easy for an agent to predict tool names.

Tool Count4/5

With 19 tools, the server covers multiple areas (Figma, git, files, workspace, releases, scanning) without feeling bloated. While slightly above the ideal range, each tool appears justified for the launcher's intended scope.

Completeness3/5

The tool surface is notably read-only; there are no tools for writing files, committing, pushing, or applying patches (despite propose_patch referencing an apply_approved_patch, which is absent). This leaves significant gaps for full workflows, though it may be intentional for a review-only launcher.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320

Related MCP Servers

ChatGPT2LocalBridge
File Systems Version Control Shell Access
Harzva
A
license
B
quality
B
maintenance
Self-hosted MCP server that enables ChatGPT to access and operate on local project files after OAuth authorization, without uploading the workspace elsewhere.
Updated 2 months ago (2026-06-26 08:56 UTC)
38
107
MIT
BridgeDesk
File Systems Shell Access
stanic-mah
A
license
Not graded
quality
A
maintenance
A desktop launcher and local MCP workspace server that enables ChatGPT and other MCP clients to securely read, edit, search, run commands, and show changes in selected local project folders.
Updated 2 months ago (2026-06-24 12:33 UTC)
1
MIT
ChatGPT Codex Bridge
Command Line File Systems Coding Agents
wei-er582
A
license
Not graded
quality
A
maintenance
Self-hosted MCP server that lets ChatGPT work with your local codebase through explicit tools.
Updated 3 months ago (2026-06-21 10:37 UTC)
MIT
Shared Credit Tool
File Systems Shell Access Version Control
Minglink
A
license
Not graded
quality
C
maintenance
Local MCP server enabling Codex and ChatGPT to read/write files, execute commands, manage processes, use Git, and inspect images on the user's machine with full privileges.
Updated a month ago (2026-07-27 18:52 UTC)
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ChampCityChris/ChampCity_GPT_MCP'

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