Skip to main content
Glama

YesTechie — UniFi Network & Security Integrator

Project

get_project

One completed YesTechie project case study in full: title, summary, tags, the write-up (typically client background and challenge, solution and equipment, results), headings, photos and videos. Use when the person wants details of a real deployment like theirs (find it with list_projects). (REST: GET /api/agent/v0/projects/{idOrSlug})

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "idOrSlug": "<idOrSlug>"
    },
    "name": "get_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
idOrSlugYesNumeric id or slug from the list tool

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden and does well by disclosing the return structure, including the typical write-up sections and inclusion of media. It does not explicitly say it is read-only or explain failure behavior for invalid ids/slugs, so it stops short of full behavioral disclosure.

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 content is front-loaded and dense, with no filler sentences. The trailing parenthetical REST endpoint is only marginally useful and the first sentence is long, keeping it from a 5.

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?

Without an output schema or annotations, the description compensates by detailing the returned contents and the tool's role in the workflow. An agent has enough information to call it correctly and understand what comes back.

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%, so the single idOrSlug parameter is already documented. The description only echoes the REST path pattern and does not add format or resolution details beyond the schema, making the 3 baseline 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 names a specific verb and resource (single completed project case study) and enumerates what it contains: title, summary, tags, write-up structure, headings, photos, videos. It clearly distinguishes from the sibling list tool by pointing to list_projects for discovery.

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

Usage Guidelines5/5

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

Explicitly states when to use it ('when the person wants details of a real deployment like theirs') and names the alternative for finding the id ('find it with list_projects'). The condition selecting this tool versus list_projects is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources