Skip to main content
Glama

Pethost

by dev.pethost
OverviewDiscussionsAdmin

GetProject

Read-onlyIdempotent

One project in full: services (state, health, image, the ports it listens on, volumes, environment, the SSH command), volumes, routes, hosts with certificates, recent operations, snapshots, the last day's HTTP traffic. Env-file values and a database's password (Project.database.connection) only with include_secret_values. Its files: ReadPath.

Input Schema

NameRequiredDescriptionDefault
project_idNo
incidents_beforeNoOnly incidents that opened before it: the oldest open_time seen, to page back. Absent = the newest.
snapshots_beforeNoOnly older snapshots: the oldest create_time seen, to page back. Absent = the newest.
snapshots_volumeNoOnly snapshots holding this volume (Volume.snapshot_count). Empty = all.
uptime_day_countNo≤90: Project.uptime_days. 0 = none.
incidents_before_idNoWith incidents_before: the incident_id of the oldest seen, so that those that opened at the same time are not skipped.
include_secret_valuesNoTrue = include env-file values (EnvironmentVariable.secret) and a database's password (Project.database.connection). To edit .env: ReadPath /.env.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / include_secret_values / description
      Previous value: -"True = include env-file values (EnvironmentVariable.secret). To edit .env: ReadPath /.env."New value: +"True = include env-file values (EnvironmentVariable.secret) and a database's password (Project.database.connection). To edit .env: ReadPath /.env."
  2. Changed3 schema fields changed
    • addedInput schema / properties / incidents_before
      Added value: +{
+  "description": "Only incidents that opened before it: the oldest open_time seen, to page back. Absent = the newest.",
+  "format": "date-time",
+  "type": "string"
+}
    • addedInput schema / properties / incidents_before_id
      Added value: +{
+  "description": "With incidents_before: the incident_id of the oldest seen, so that those that opened at the same time are not skipped.",
+  "type": "string"
+}
    • addedInput schema / properties / uptime_day_count
      Added value: +{
+  "description": "≤90: Project.uptime_days. 0 = none.",
+  "minimum": 0,
+  "type": "integer"
+}
  3. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the exact data surface returned, and the sensitive-data constraint that env-file values and database passwords (Project.database.connection) appear only with include_secret_values. No contradiction with annotations.

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?

Dense but front-loaded: the data surface is listed first, then the secrecy caveat, then the file-handling pointer. Every clause conveys return content or a constraint; slightly long but nothing feels 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?

There is no output schema, so the description must carry the return-value burden — and it does, enumerating the returned collections and the secret-gating rule. For a read-only project getter this is nearly complete; only the pagination-parameter interplay (incidents_before/snapshots_before) is left to the schema.

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 86%, so the baseline is 3, but the description reinforces the most consequential parameter — include_secret_values — including what is gated (env values, DB password) and where to edit .env instead. This adds meaning and safety guidance beyond the schema text.

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?

States a specific verb+resource ('one project in full') and enumerates the returned sub-resources (services, volumes, routes, hosts, snapshots, HTTP traffic), so the agent knows exactly what it retrieves. It is distinguishable from GetMachine and GetOperation by the project scope, though it never names those siblings explicitly.

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 implied (this is the full-project getter) rather than stated. The one routing hint given — 'Its files: ReadPath' — points away for file content, but there are no when-to-use/when-not conditions or alternatives for the project data itself.

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

All Pethost toolsInspect
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.

Resources