search_codesFree-text search across brands, categories and offers, e.g. 'stock perps discount', 'esim', '20% off exchange'. Returns matching verified-code records.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms |
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | ||
| results | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "aliases": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "benefit": {
+ "type": "string"
+ },
+ "benefit_detail": {
+ "type": "string"
+ },
+ "brand": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "country_notes": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "expires_at": {
+ "description": "The publisher's codes have no expiry date.",
+ "type": "null"
+ },
+ "how_to_apply": {
+ "type": "string"
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "last_verified": {
+ "description": "ISO date of the historical check recorded in the verification log, not an expiry date.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "review_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signup_url": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "status": {
+ "const": "active",
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "validity": {
+ "const": "no-expiry",
+ "type": "string"
+ },
+ "verification_log_url": {
+ "type": "string"
+ },
+ "verification_methods": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "brand",
+ "slug",
+ "category",
+ "code",
+ "benefit",
+ "benefit_detail",
+ "status",
+ "validity",
+ "expires_at",
+ "last_verified",
+ "verification_methods",
+ "verification_log_url",
+ "aliases",
+ "country_notes",
+ "url",
+ "review_url",
+ "signup_url",
+ "how_to_apply",
+ "keywords"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "count",
+ "results"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety and completeness profile. The description adds that results are 'matching verified-code records,' but does not discuss ordering, result limits, or empty-result behavior. With annotation coverage, a 3 is appropriate.
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?
One tightly written sentence that front-loads the action and scope, then illustrates with examples. Every clause carries useful information and there is no repetition of the schema or annotations.
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-parameter, read-only search tool with full schema documentation and an output schema present, the description provides everything an agent needs to invoke it correctly. The examples and scope statement remove ambiguity about query intent.
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?
Schema coverage is 100%, so the 'query' parameter is already documented as 'Search terms.' The description goes beyond this by explaining the free-text nature and giving three diverse example queries that clarify expected phrasing and scope. This adds genuine value.
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?
States a specific verb ('search'), resource ('verified-code records'), and search surface ('brands, categories and offers'). The title and description clearly differentiate it from siblings: get_code is for looking up a specific code and list_brands is for listing brands, not free-text searching.
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?
Provides clear usage context with concrete examples ('stock perps discount', 'esim', '20% off exchange') that tell an agent what kind of queries belong here. It does not explicitly name when-not-to-use it or point to get_code/list_brands as alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The three tools serve distinct lookup modes: direct brand lookup, structured category browsing, and free-text search. There is minor overlap because list_brands and search_codes both return code information, but their intended use cases are clear enough to avoid major misselection.
All tool names follow a consistent verb_noun pattern: get_code, list_brands, search_codes. This makes the tool set predictable and easy for an agent to reason about.
Three tools is well-scoped for a read-only verified-codes lookup service. Each tool covers a distinct access path—single record, list by category, and full-text search—without unnecessary duplication.
The domain is retrieving verified discount/code information, and the tool set covers direct retrieval, browsing by category, and free-text discovery. Since this appears to be a read-only data source, no create/update/delete operations are expected, so there are no obvious dead ends.