Aident AI

capabilities_feedback

Report feedback about capability usage or capability search quality. Use targetType="capability" after using a capability to rate performance, reliability, correctness, latency, auth friction, or execution problems. Also use it for unclear instructions, missing schemas, or stale metadata on a specific capability. Use targetType="search" when the search results were irrelevant, incomplete, duplicated, or poorly ranked.

Input Schema

TableJSON Schema

Name	Required	Description
`tags`	No	Feedback quality or issue tags.
`rating`	No	Optional quality rating, especially for capability usage feedback.
`comment`	No	Short explanation of what was wrong or useful.
`context`	Yes	Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
`surface`	No	Optional caller surface such as codex or claude-code.
`llm_model`	Yes	The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
`targetType`	Yes	Whether feedback targets a capability usage/details experience or a search result set.
`searchQuery`	No	Search query when targetType="search".
`capabilityId`	No	Capability id/name when targetType="capability".
`agentSessionId`	No	Optional session id for external callers.
`capabilityType`	No	Capability type when targetType="capability".
`searchResultIds`	No	Optional capability ids returned by the problematic search.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 14, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / context

Added value: +{
+  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
+  "type": "string"
+}

addedInput schema / properties / llm_model

Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "targetType"
-]New value: +[
+  "targetType",
+  "context",
+  "llm_model"
+]

First observedAug 7, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already signal readOnlyHint=false and destructiveHint=false, so the description is consistent with a write-but-not-destructive feedback action. It adds useful context about what kinds of problems can be reported, such as auth friction, missing schema, and stale metadata. It does not disclose whether feedback is persisted or whether it influences future behavior, but the lightweight annotations lower the bar here.

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?

Three sentences with no filler: the purpose is front-loaded in the first sentence, and the next two sentences map directly to the targetType enum values. Every sentence earns its place.

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?

Given 12 parameters and 100% schema coverage, the description plus schema covers the required fields and targetType selection logic well. There is no output schema, and for a feedback-reporting tool the lack of return-value documentation is acceptable. A brief note about when to use skills_feedback instead would make it fully complete, but it is not a blocker.

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 description coverage is 100%, so the baseline is 3. The tool description adds meaning beyond the schema by mapping targetType values to concrete scenarios, e.g., using targetType="search" when results are irrelevant or duplicated. This helps the agent decide which of the optional search/capability fields are relevant. Rating and tags remain documented by the schema, which is acceptable.

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?

Opens with a specific verb and object: 'Report feedback about capability usage or capability search quality.' It immediately names the resource and domain, and the targetType distinction further disambiguates the two modes. This is clearly distinguishable from siblings like capabilities_search or skills_feedback.

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?

The description explicitly states when to use targetType="capability" (after using a capability, to rate performance, reliability, latency, auth friction, etc.) and when to use targetType="search" (irrelevant, incomplete, duplicated, or poorly ranked results). It does not explicitly name skills_feedback or loadout_bug_submit as alternatives, so cross-tool exclusions are implied rather than stated.

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

All Aident AI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?