Server4Agent

Get project details

get_project

Read-only

Get a single project: name, slug, description, public URL, listen port, run plan, timestamps. listen_port is the port inside the box that this project's URL is routed to, so an app here binds that rather than a port of its own choosing, and has to be running for the URL to answer. listen_port is null on a project created before the field existed, and on a box old enough to predate the in-pod proxy the published port (8080) is reached directly instead, so treat those two as the fallback when an app that binds listen_port still cannot be reached. url_status covers only whether the address and its certificate are ready, so it reads "active" for a public project with nothing listening; it is not a health check. run_plan is how bring-up installs and starts it, or null if no plan has been settled yet; a run_plan whose port is null means the project isn't a server.

Input Schema

Name	Required	Description	Default
`project_id`	Yes	The project's id, as returned by create_project or list_projects.

Output Schema

Name	Required	Description
`id`	Yes	Project id.
`url`	No	Public URL. null while the project is private.
`name`	No	Project name.
`slug`	No	URL slug. Stays the same when visibility changes.
`access`	No	Who may open the URL once it is public.
`source`	No	What the workspace was seeded from: kind plus git_url, ref, subdir, or archive_path.
`run_plan`	No	How bring-up installs and starts the project: stack, install, start, port, env, notes. null until one is settled.
`template`	No	Template id it was created from.
`lifecycle`	No	ephemeral projects are removed with cleanup_project.
`server_id`	Yes	The server the project lives on.
`created_at`	No	ISO 8601 timestamp.
`init_phase`	No	Where bring-up has got to, for a project seeded from a source.
`updated_at`	No	ISO 8601 timestamp.
`url_status`	No	Whether the address and certificate are ready. Not a health check.
`visibility`	No	public = live at url. private = not publicly reachable.
`cert_status`	No	State of the shared certificate. null while private.
`description`	No	One-line description.
`listen_port`	No	The port inside the box this project's URL is routed to.
`runtime_status`	No	Whether the project is running or paused.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A3.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 genuinely non-obvious behavioral context: url_status is explicitly not a health check, listen_port can be null on legacy projects requiring the published 8080 fallback, and run_plan may be unsettled. These caveats prevent real misinterpretation, though error/not-found behavior is unaddressed.

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?

The purpose is correctly front-loaded in one clean sentence, but it is followed by a dense three-part exposition on output-field semantics that reads as documentation for the return payload rather than the tool call. Every clause is factual, yet the block is long and unstructured relative to a one-parameter read.

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 an output schema present, the description need not explain return values, yet it goes further and clarifies the traps in those values, which makes it more than complete on that axis. The remaining gap is failure modes and whether listing alternatives exist, which for a simple single-resource read is minor.

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 the single project_id parameter is fully documented as coming from create_project or list_projects. The description adds nothing about the parameter itself, so baseline 3 applies with the schema doing all the work.

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 first sentence states a specific verb and resource and enumerates the exact fields returned (name, slug, description, URL, listen port, run plan, timestamps). It is unambiguous about what the tool does, but it never contrasts itself with siblings like list_projects or get_run, so the agent must infer the distinction from the name alone.

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?

Usage is only implied: the required project_id and the schema note that ids come from create_project or list_projects hint at the retrieval workflow. There is no explicit statement of when to call this versus list_projects for a batch, nor what to do when the project is missing.

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

All Server4Agent tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.