server_infoWhat Measure Tech PRO is and what this server offers. Measure Tech PRO is a full CRM for contractors, available today on iPhone, iPad, and Mac. The web console for the office opens soon. Returns the product summary, the knowledge-base size, and where the other surfaces live.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, so the read-only promise is covered and 'Returns' aligns with that. The description adds useful product context such as platform availability and the upcoming web console, but it does not describe the response format or any operational quirks. With no output schema, adding return-structure detail would improve transparency.
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 three short sentences with no filler. The lead sentence states the tool's role, and the following sentences supply product facts and expected output. It is front-loaded and every sentence earns its place.
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?
For a no-argument, read-only info endpoint, the description clearly states what the tool returns and gives the product context needed to decide whether to call it. It is complete enough to invoke safely, although the exact JSON shape is unspecified; with no output schema, a bit more return-structure detail would make it fully self-contained.
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 tool exposes zero parameters, so there are no parameter semantics for the description to clarify. Under the rubric, 0 params earns a baseline of 4 because no description compensation is necessary; schema description coverage is vacuously complete.
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?
The description uses a specific verb ('Returns') and identifies a concrete resource: Measure Tech PRO and what the server offers. It names three distinct outputs (product summary, knowledge-base size, surface locations), making the tool's role clear. It does not explicitly contrast with the sibling get_product_overview, but the server-level scope is evident.
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?
The description provides clear context: call this tool for a high-level orientation about Measure Tech PRO, including platform availability and server-provided information. It does not name sibling alternatives or exclusions, but the zero-parameter interface and explicit return list make the intended use fairly unambiguous.
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.
Most tools map to a clear resource/action, but get_product_overview and search_knowledge_base both claim to answer 'does it do X', and search_forum and get_roadmap both surface statuses, so an agent could pick the wrong one. The descriptions reduce the ambiguity but do not fully eliminate it.
The set uses lower_snake_case and broadly follows a verb_noun shape with get_/search_ prefixes for reads. However, my_requests and server_info are noun phrases and comment_on_request inserts a preposition, so the pattern is not perfectly uniform.
At 13 tools, the count is well within a reasonable range for the scope: product info, pricing, forum search/read/write, hearts/comments, waitlist, contact, and personal status. Each tool covers a distinct interaction area and none feels redundant enough to cut.
The surface covers the main customer journeys: learn about the product, search/read forum, post/comment/heart, check personal requests, ask for contact, and join the waitlist. Minor gaps exist (e.g., no edit/delete for comments or a way to check waitlist status), but agents can complete core workflows without dead ends.