Skip to main content
Glama

get_authors

List authors linked to one claim.

Use this when you have a claim id and need the people linked to it.
Returns author id, name, and orcid. The list is empty when none are linked.
Example: get_authors(claim_id="claim-attention").
Example: get_authors(claim_id="<id from query_claims>").

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": {
      "claim_id": "<claim_id>"
    },
    "name": "get_authors"
  }
}

Input Schema

NameRequiredDescriptionDefault
claim_idYesClaim id returned by a search tool. Example: claim-attention.

Output Schema

NameRequiredDescriptionDefault
authorsNo
claim_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose the return fields (id, name, orcid) and the empty-list case when no authors are linked, which is useful, but says nothing about read-only behavior, ordering, or limits.

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?

Opening sentence is front-loaded with purpose, followed by usage, return shape, and examples. The two examples are somewhat redundant since both convey the same claim_id usage, which is minor padding.

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?

For a simple one-parameter lookup with a 100%-covered schema and an output schema, this covers purpose, when to use, empty-result behavior, and id provenance. Missing only edge-case behavior such as invalid claim ids.

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?

Schema coverage is 100%, so the single claim_id parameter is already documented, and the schema itself notes it comes from a search tool. The description restates that provenance via the '<id from query_claims>' example but adds no format or validation detail beyond the schema.

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?

States a specific verb and resource with clear scope: 'List authors linked to one claim.' The one-claim scope plus the returned fields distinguish it plainly from siblings like get_evidence, get_contradictions, and query_claims.

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 'Use this when you have a claim id and need the people linked to it,' and the second example points to query_claims as the source of the id. It gives clear context but doesn't state when not to use it or name an alternative lookup path.

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