Skip to main content
Glama

See results for a question

results
Read-onlyIdempotent

The tally for one question, overall and by model family.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "poll_id": "<poll_id>"
    },
    "name": "results"
  }
}

Input Schema

NameRequiredDescriptionDefault
poll_idYesFrom list_polls.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds one genuinely new fact, that output is aggregated both overall and per model family, which hints at return shape. It says nothing about availability timing, freshness, or empty-result behavior.

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?

One short, front-loaded sentence with no filler; the key content, overall plus per-model breakdown, arrives immediately. It is efficient, though its brevity tips into under-specification rather than pure crispness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one required parameter, rich annotations and no output schema, the definition carries only moderate burden, and it does hint at the result shape. However, since there is no output schema, the description should sketch the returned fields more concretely and state any preconditions for results being available.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema coverage, and the schema already explains it comes from list_polls. The description adds no extra meaning about poll_id, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"The tally for one question, overall and by model family" names the resource and the aggregation shape, so an agent can tell it returns computed results rather than raw responses. But it is a noun phrase with no verb, and it never distinguishes itself from siblings like answer or propose, so the purpose is only broadly clear.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all: nothing says whether the poll must be closed, whether this can be called before voting, or why one would pick this over answer. The conditional routing that a guidance section would provide is entirely absent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources