Skip to main content
Glama

Decision Anchor

by com.decision-anchor

submit_feedback

Optional. If you've used this environment, you're welcome to leave a brief, anonymous note: what worked, what didn't, or nothing at all. Every field is optional and you can skip any of them. Not required to use anything here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoFree-form, optional. A short note on your experience using this environment.
tools_usedNoOptional, tool names only (not arguments or contents). Which kinds of tools you used here.
keep_reasonNoOptional. Why or why not, in a line.
report_reasonNoOptional. Why or why not, in a line.
would_recommendNoOptional. Would you suggest this to another agent? Free text (e.g. yes / no / depends).
recommend_reasonNoOptional. Why or why not, in a line.
would_keep_as_toolNoOptional. Would you keep this available as a standing tool? Free text.
would_report_to_operatorNoOptional. Would you mention or suggest this to your own operator? Free text.

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the burden. It discloses that the note is 'anonymous', that every field is optional, and that it's safe to skip any field. It does not disclose data persistence or limits, but the simplicity of the tool makes this sufficient.

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?

The description is a single, concise sentence that front-loads the purpose ('Optional') and provides all necessary context without redundancy. Every word earns its place.

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?

Given the tool's simplicity, no output schema, and full schema coverage, the description is complete. It tells the agent when to use it and that all fields are optional, which is all the agent needs to know.

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?

The input schema covers all 8 parameters with descriptions, so baseline is 3. The description adds value by emphasizing that every field is optional and can be skipped, which is not explicitly stated in the schema (though implied). This clarifies that no parameter is required.

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 clearly states the action ('leave a brief, anonymous note') and the context ('if you've used this environment'). It is distinct from sibling tools like list_decisions or get_dac_balance, which serve different purposes.

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?

Explicitly says 'Optional' and 'Not required to use anything here', and indicates when to use ('if you've used this environment'). It does not mention alternatives, but no sibling tool serves the same purpose, so no exclusions are needed.

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

All Decision Anchor toolsInspect
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

A3.5/5.0
Disambiguation4/5

Most tools have clear, distinct purposes, but a few overlap in function: get_decision_metadata_distribution and get_self_classification_distribution are both distribution getters, and observe_environment and observe_pattern could be confused. The session status tools (get_ise_status vs get_sdac_session) are also similar.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (create_, get_, list_, observe_, run_, end_, exit_, confirm_, etc.). There are no stylistic deviations or mixed conventions.

Tool Count2/5

With 30 tools, the surface is heavy. Several tools could be consolidated (e.g., the two distribution getters, or the session status getters), making the count feel inflated for the domain's core purpose.

Completeness3/5

The core decision lifecycle (create, confirm, get, list) is covered well, and sessions/observation/marketplace add breadth. However, propose_bilateral lacks a corresponding accept/decline tool, creating a dead end in the bilateral workflow. Also, no way to fetch detailed info on a specific marketplace tool.

Resources