Get one exact public SOURCE or SOURCE_GROUP. Composite-looking source IDs are opaque and are never split.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceId | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| sources | Yes | ||
| coverage | No | ||
| evidence | Yes | ||
| freshness | Yes | ||
| citationUrl | No | ||
| limitations | Yes | ||
| schemaVersion | Yes | ||
| knowledgeVersion | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds non-redundant context by saying the resource is public and that composite-looking IDs are opaque and never split, which prevents an agent from misinterpreting the ID format. It does not explain not-found behavior, but the output schema and read-only annotations reduce the need for that here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action is front-loaded, and the critical opaque-ID warning is placed in the second sentence where it is easy to retain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-required-parameter, read-only, idempotent lookup with an output schema, this definition is complete enough for correct invocation. The schema covers the parameter constraint, annotations cover side-effect safety, and the description clarifies the ID semantics and public scope. No essential operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameter descriptions in the schema, the description carries the semantic load. It says sourceId identifies a public SOURCE or SOURCE_GROUP and adds the key warning that seemingly composite IDs are opaque and must not be split. This is meaningful beyond the structural pattern, though it does not enumerate example IDs or distinguish how source-group values are represented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and object: 'Get one exact public SOURCE or SOURCE_GROUP'. It also adds a distinguishing semantic—'Composite-looking source IDs are opaque and are never split'—so the operation is clearly an exact opaque-ID lookup rather than a search or aggregate. It does not explicitly contrast with sibling tools, so it misses the highest bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording 'one exact' and 'SOURCE or SOURCE_GROUP' implies the tool should be used when the agent already has a concrete source identifier and needs its context. It also warns against constructing or splitting composite-looking IDs, which guides call construction. However, it never names alternatives or states when not to use this tool, leaving the boundary with search_vehicle_knowledge and the other get_* context tools to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.