Skip to main content
Glama

assess_result

Retrieve the assessment scaffold for one domain, including reachable signalling questions, accepted answers, evidence requirements, and cue search hits. Use it to answer only the questions the algorithm actually reaches.

Instructions

Return the assessment scaffold for ONE domain: the questions actually in play, their own-words intent, the response vocabulary each accepts, what evidence each answer must carry, and the cue searches already run against this bundle with their hits.

THE SCAFFOLD IS PER DOMAIN BY DESIGN. Most signalling questions are unreachable on any given path — 24 of 41 were never reached on the reference assessment — and which of domain 1's two question sets exists at all is decided by C4. There is no flat 41-question rubric to fetch, and asking for one would mean answering questions the algorithm discards.

domain=0 (default) returns the overview: the preliminaries, what is settled, which domains are done, and which are outstanding. domain=1..6 returns that domain's scaffold. Domain 1 is refused until P1 is set.

Work a domain at a time: read the cues to find where the evidence is, answer only the questions the algorithm reaches, then submit_answers. You do not state a judgement — the server computes it from your answers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNo
result_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cuesNo
domainNo
variantNo
citationNo
algorithmNo
low_labelNo
questionsNo
result_idNo
structureNo
applies_ifNo
depends_onNo
text_sha256No
domain_labelNo
instructionsNo
spec_versionNo
answer_schemaNo
max_judgementNo
preliminariesNo
variant_labelNo
evidence_modesNo
low_label_noteNo
assessment_unitNo
confounding_noteNo
domains_completeNo
supplement_statusNo
max_judgement_noteNo
domains_outstandingNo
assessment_unit_noteNo
prespecified_confoundersNo
Behavior5/5

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

With no annotations, the description carries the full burden and does well. It discloses the per-domain design, the default domain=0 overview, the refusal condition for domain 1 until P1 is set, and the fact that the server (not the agent) computes judgement. These are non-obvious behavioral traits that help avoid misuse.

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 description is a dense paragraph, front-loaded with the main purpose and packed with necessary caveats (per-domain, unreachable questions, refusal, workflow). It is somewhat long but each sentence adds essential context, so it earns its place rather than being wasteful.

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 complexity (per-domain scaffolds, conditional refusal, workflow), the description covers the key usage steps, domain semantics, and behavioral constraints. An output schema exists, so return values are covered by that; the description fills in the strategic context (work one domain at a time, then submit answers, server judges).

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 0%, so the description must compensate. It clearly explains domain: default 0 returns overview, 1..6 return scaffolds, and 1 is refused until P1 is set. For result_id, it is referred to as 'this bundle' in the context of cue searches, implying it identifies the result bundle, though not as explicitly as domain.

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 states a specific verb+resource: 'Return the assessment scaffold for ONE domain' and enumerates the scaffold's contents (questions, intent, vocabulary, evidence, cue searches). It also distinguishes this from a hypothetical flat 41-question rubric, making it clear this is per-domain only.

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?

It explicitly says when to use: 'Work a domain at a time' and then 'submit_answers' as the next step. It also gives a when-not-to-use: 'There is no flat 41-question rubric to fetch' and explains why asking for one would be wrong. This is clear contextual guidance with an alternative workflow.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Black-Swan-Causal-Labs/robins-i-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server