DeployIt Product Expert

Ask the product expert

ask_product_expert

Ask a question about "deployit" and get an answer verified against its live source code and git history. Use it for anything about product behavior, features, settings, limits, error messages, or recent changes.

HOW IT WORKS AND HOW LONG IT TAKES: the expert genuinely investigates — it searches and reads the product's real source code before answering. A fresh investigation takes 20-60 SECONDS. Do not give up early, and if a human is waiting, tell them the verified answer may take up to a minute. Repeated questions asked without context are served from cache in under a second; the cache resets whenever the product's code changes.

IF IT TIMES OUT: you get an error saying the expert could not finish in time. The investigation KEEPS RUNNING in the background — re-ask the IDENTICAL question (same wording, no context) about a minute later and the finished answer is served instantly from cache. Retry with the same words; rephrasing restarts the investigation.

READING THE ANSWER: it ends with a Sources block (the files and commits actually consulted) and a Verification status carrying both confidence and polarity:

verified: confirmed in the code — safe to relay.
backend_only: the capability exists server-side but has no visible UI path.
not_found: searched, and it does NOT exist — a factual "no", relayable as such.
unknown: the expert could not conclude — do NOT relay as fact; consider retrying with depth "thorough".

LIMITS: strictly read-only — it can never change anything. Some topics may be refused by the project's policy. A monthly question quota may apply (the error message says so when reached; cached answers never count). At most 60 requests per minute per access key.

Input Schema

TableJSON Schema

Name	Required	Description
`depth`	No	quick (default): up to ~1 minute of investigation, right for support questions. thorough: digs much deeper for hard questions — expect the timeout-then-retry-from-cache flow.
`context`	No	Optional context from your own conversation with the end user (symptoms, plan, what they tried…). Makes the answer more targeted, but context-carrying questions are never cached — omit it for generic questions.
`question`	Yes	The question about the product, as specific as possible. Identical wording hits the cache — when retrying after a timeout, repeat the question verbatim.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers richly: it explains the tool searches source code, takes 20-60 seconds, has timeout/background-retry behavior, caching semantics, output verification statuses, read-only guarantees, quota limits, and rate limits. This is exceptional transparency beyond any structured annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, every sentence earns its place. The description is organized into labeled sections, front-loads the core purpose, and packs high-value operational detail without filler. The length is justified by the tool's complexity and lack of annotations/output schema.

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?

The description covers what the tool does, when to use it, timing expectations, timeout behavior, how to read the answer, verification status meanings, safety limits, quota, and rate limits. With no output schema and no annotations, this is a complete operational guide for correct invocation and interpretation.

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 100%, so the baseline is 3. The description adds valuable parameter-level meaning: identical 'question' wording hits the cache, retries must be verbatim, 'context' disables caching, and 'depth: thorough' is suggested when status is unknown. This goes beyond the schema.

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 description uses a specific verb and resource: 'Ask a question about deployit' and states the outcome ('answer verified against its live source code and git history'). It enumerates the topics it covers, but it does not explicitly differentiate from siblings like get_recent_changes, so it stops short of full 5-level distinction.

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

Usage Guidelines4/5

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

It explicitly says 'Use it for anything about product behavior, features, settings, limits, error messages, or recent changes,' giving clear context for when to invoke the tool. However, it does not say when not to use it or compare it to alternate tools, so it lacks a true exclusion/alternative statement.

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

All DeployIt Product Expert tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

The tools are mostly distinct: server_info is clearly separate, and get_recent_changes is explicitly positioned as the fast first stop for change-related questions while ask_product_expert handles deeper investigation. Some overlap exists around 'recent changes', but the descriptions provide clear routing guidance.

Naming Consistency4/5

Two tools follow a clear verb_prefix pattern (ask_product_expert, get_recent_changes), but server_info breaks the pattern by being a plain noun phrase. This is a minor deviation rather than a chaotic mix, so the set remains readable and predictable.

Tool Count5/5

Three tools is well-scoped for the stated purpose: deep product Q&A, fast changelog retrieval, and server/index orientation. Each tool earns its place and none are redundant.

Completeness5/5

The tool surface covers the full knowledge-retrieval flow: orient with server_info, get immediate change summaries with get_recent_changes, and perform deep investigation with ask_product_expert. Answers include sources and verification statuses, so there are no obvious dead ends or missing operations for this domain.

Resources

Need Help?