get_projectGet detailed information about a project, including its environments. Use this when you already have the project id; to browse the organization's projects use list_projects. Requires organization context (call set_context first). If no projectId is given, uses the active project context.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Public ID (GUID) of the project. If omitted, uses the active project context. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals no side effects, and the description adds useful behavioral context about requiring organization context and falling back to the active project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description clearly conveys what the tool returns and the conditions under which it operates, making it complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the parameter fully, and the description adds meaningful clarification by explaining the GUID format and the behavior when projectId is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Get detailed information about a project') and explicitly distinguishes itself from list_projects, making its purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool (when project id is already known), when to use the alternative (list_projects), and notes the prerequisite to call set_context first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.