ExD Accelerator MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
Each tool targets a distinct resource and action, with clear separation between schema field operations, offer management, placement, rules, strategies, and CSV parsing. Even similar tools like deprecate_oob_field and deprecate_schema_field are explicitly differentiated by the type of field.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern in snake_case, with verbs like create, get, list, update, deprecate, detach, parse, and bulk_create. The minor variation between get_, list_, and lookup_ is logically consistent with the cardinality of the result (single vs multiple).
Tool Count4/5
At 21 tools, the count is slightly above the ideal 3-15 range, but the complexity of the ExD domain (schema management, multiple resource types, CSV parsing, auditing) justifies this number. Each tool serves a specific purpose without redundancy.
Completeness3/5
The tool set covers creation and reading for most resources, but lacks delete operations for offers, placements, rules, formulas, and strategies. Update is only available for offers. This leaves notable gaps that may require manual intervention or cause agent failures.
Average 3.5/5 across 21 of 21 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only mentions the confirmed flag, failing to address side effects (e.g., immediate activation, permissions needed, rollback possibility), rate limits, or any other behavioral context. This is critically insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus a requirement), which could be seen as concise, but it is too sparse to be functional. For a tool with 7 parameters, it lacks essential details. It is front-loaded with the main action but fails to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain what a ranking formula does, how formula types differ, what the confirmed flag actually controls, or any interaction with other decisioning tools. This leaves an AI agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only name and formula_type have descriptions). The description adds no explanation for parameters like custom_pql, custom_field_name, description, or access_token. It does not clarify the meaning of formula_type enum values or how they relate to the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a ranking formula for Experience Decisioning', clearly identifying the action (create) and resource (ranking formula) within a specific domain. It does not explicitly differentiate from sibling tools like create_eligibility_rule, but the context provided by the domain name helps distinguish it.
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?
The description mentions 'Requires confirmed: true to execute', which provides a basic condition but offers no guidance on when to use this tool versus alternatives, no prerequisites, and no explanation of formula types or their appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states 'Read-only,' which is a single behavioral trait. It does not disclose auth requirements, pagination behavior, rate limits, or any side effects, which are important for a list operation.
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 single sentence of 10 words, which is very concise. However, it may be under-specified, trading completeness for brevity. Nonetheless, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no output schema, no annotations), the description is incomplete. It fails to explain the return format, possible pagination, what 'compatible with the Offer Item class' means, or how to interpret results. The agent lacks sufficient context to use the tool effectively without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any parameter semantics. The two parameters ('access_token' and 'include_global') are not described, leaving the agent without guidance on what they do or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all tenant fieldgroups') with a constraint ('compatible with the Offer Item class'). It also notes it is read-only. However, it does not explicitly differentiate from sibling tools like 'get_fieldgroup' or 'create_offer_metadata_fieldgroup', but the purpose is sufficiently 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?
No guidance on when to use this tool vs. alternatives. It does not mention prerequisites, exclusions, or context for when to choose this over similar tools like 'list_schema_descriptors' or 'get_fieldgroup'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the endpoint used ('/exd-placements') and the necessity of 'confirmed: true', but lacks details on side effects, authorization needs, or other behavioral traits. With no annotations, the description carries the full burden and does a minimum but adequate job.
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?
Two concise sentences that front-load the purpose and critical requirement. No fluff, but could be slightly expanded for key parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain core concepts like placements or channel types, making it hard for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions 'name', 'channel', and 'confirmed' indirectly, with some semantics for 'confirmed'. Other parameters (status, description, access_token) are not explained. Insufficient for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a channel placement for Experience Decisioning, with specific verb and resource. However, does not distinguish from sibling creation tools like bulk_create_offers or create_collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a key requirement: 'Requires confirmed: true to execute.' This gives usage guidance but no comparison to alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only states 'Read-only', which is minimal. With no annotations, description should disclose more about authentication, error handling, rate limits, or response format, but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 13 words, front-loaded with purpose. No unnecessary words, highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given lack of output schema and annotations, and only 2 parameters, the description is too brief. Does not specify what 'full field definitions' includes, no example usage, no constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It mentions 'by its altId' which loosely maps to fieldgroup_id, but there is mismatch in naming. Does not explain access_token or provide any parameter details.
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?
Clearly states the verb 'Fetch', the resource 'full field definitions inside a specific fieldgroup', and the identifier 'by its altId'. Distinguishes from siblings like list_schema_fieldgroups which list fieldgroups, not their contents.
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?
No explicit guidance on when to use or when not to use. Does not mention prerequisites, alternatives, or context compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only reveals the confirmation requirement, but omits other behaviors like idempotency, error conditions, or effects on existing fields.
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 concise (two sentences) and front-loaded with the main action. However, it could be more structured with parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description is too minimal. It fails to explain what each parameter does, how the tool behaves beyond the confirmation flag, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It only explains the 'confirmed' parameter implicitly. The remaining 7 parameters (e.g., field_name, field_type) are left to the agent to infer from their names.
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 clearly states the action ('Add a single new field') and the resource ('existing tenant fieldgroup'). It distinguishes from sibling tools like deprecate_schema_field or bulk_create_offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires confirmed: true to execute') but does not provide guidance on when to use this tool versus alternatives, such as bulk_create_offers or deprecate_schema_field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions the 'confirmed' requirement and implies a write operation, but does not detail side effects, error handling, or whether it creates or updates a strategy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and adding a key requirement. Every sentence is essential, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema, but the description omits what the tool returns (e.g., created strategy ID). It also lacks details on how parameters like priority or description interact, leaving the agent underinformed.
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 description coverage is 50%, so the description has room to add parameter context. However, it only implicitly references collection, eligibility_rule, and ranking_formula, and adds 'confirmed' requirement. It does not explain non-obvious parameters like description, priority, or access_token.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Wires a collection, eligibility rule, and ranking formula into a selection strategy,' which clearly indicates the action and resources involved. It distinguishes from sibling tools that create individual components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement 'confirmed: true to execute,' which is a usage condition. However, it does not provide guidance on when to use this tool versus alternatives, such as creating components separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only' behavior and result ordering ('newest first'). With no annotations, the description partially shoulders the transparency burden but omits other potential traits like rate limits, pagination, or effect on system state. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys purpose, scope, ordering, and read-only nature. No unnecessary words.
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?
For a simple read-only tool with one parameter, the description covers the main purpose and ordering. However, it lacks parameter explanation and usage guidance, making it only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one optional parameter (access_token) with 0% schema description coverage. The description does not mention the parameter at all, providing no meaning beyond the schema. This is a significant gap.
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 clearly states 'Fetch the full audit log for the decisioning schema', specifying the verb 'Fetch' and the resource. It adds scope details ('every change ever made, newest first') and distinguishes it from sibling mutation or schema management tools.
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?
No explicit guidance on when to use this tool versus alternatives. The description merely states 'Read-only' but does not explain when to prefer this over other tools like list_schema_descriptors or get_fieldgroup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It declares the tool is 'Read-only', which indicates no side effects. However, it does not explain what 'resolved' means, potential performance implications, or authentication requirements beyond the implied access_token parameter.
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 extremely concise (one sentence plus 'Read-only') with no unnecessary words. However, it sacrifices parameter documentation for brevity, which limits its utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no annotations, the description should cover parameter meanings and output expectations. It fails to do so, leaving the agent uncertain about how to invoke the tool and what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no information about the two parameters ('access_token', 'include_deprecated'). The user receives no guidance on their purpose, requiredness, or acceptable values, which is a significant deficiency.
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 clearly states the action ('Fetch') and the resource ('full resolved Personalized Offer Items decisioning schema'), including what it contains (all fieldgroups, OOB fields, custom tenant fields). It distinguishes this tool from siblings like 'get_fieldgroup' and 'list_schema_fieldgroups' by specifying the full resolved schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for fetching the full resolved schema, but does not explicitly state when to use it versus alternatives like 'get_fieldgroup' or 'list_schema_fieldgroups'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It states 'Read-only', which is a key behavioral trait. However, it does not disclose authentication requirements, rate limits, pagination behavior, or what happens if access_token is missing. For a simple list tool, this is minimally sufficient.
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 extremely concise—just two short statements. Every word serves a purpose. However, it could be slightly more structured by explaining parameters. No wasted text.
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?
Given the tool's simplicity (list operation, single optional param, no output schema), the description covers the basic purpose and read-only nature. But it lacks details on return format, pagination, or how to interpret results. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description fails to mention the single parameter 'access_token' at all. The agent receives no guidance on what this parameter is for, its format, or necessity. This is a significant gap.
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 clearly states the verb 'List', the resource 'descriptors on the decisioning schema', and enumerates specific descriptor types (identity, deprecation, display name overrides, relationships). It also adds 'Read-only' to indicate safety. This distinguishes it from sibling tools like list_offer_items or list_schema_fieldgroups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool. The description implies use for viewing schema descriptors but does not compare to alternatives or mention prerequisites. This is adequate but lacks deeper context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only discloses that the tool requires 'confirmed: true' to execute, but does not mention idempotency, error states, or side effects like whether the rule is immediately active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences, each adding value: the first states the purpose and domain, the second provides a critical usage constraint. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is too brief. It explains a single behavioral constraint but omits expected return values, error scenarios, or prerequisites beyond 'confirmed: true'. This leaves the agent with significant unknowns.
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 description coverage is 40% with documented parameters 'name' and 'pql_expression'. The description adds the requirement that 'confirmed' must be true, which supplements the schema where 'confirmed' has no description. This somewhat compensates for the low coverage, but the 'access_token' and 'description' parameters remain undocumented.
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 clearly states the verb 'Create' and resource 'PQL eligibility rule for Experience Decisioning,' which matches the tool name and distinguishes it from siblings like 'create_collection' or 'create_selection_strategy.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a precondition ('Requires confirmed: true to execute') but does not provide explicit guidance on when to use this tool versus alternatives, such as 'create_selection_strategy' or 'create_ranking_formula.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses the confirmation requirement as a behavioral trait (a write with a safety mechanism), but lacks details on idempotency, failure behavior, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences totaling 18 words—and front-loads the primary purpose. Every word serves a purpose with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, the description is insufficient. It omits what the collection is used for, error handling, return values, and how filter constraints work in detail.
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?
The input schema has 71% description coverage. The description adds 'with a filter constraint', which relates to filter_type and filter_value but does not explain parameters like access_token or the description field where schema lacks descriptions. It provides no additional parameter meaning 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?
The description clearly states the verb 'create' and the resource 'offer item collection' with the specific feature 'with a filter constraint'. This distinguishes it from sibling tools like 'bulk_create_offers' or 'create_eligibility_rule'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage guideline: 'Requires confirmed: true to execute.' However, it does not explain when to use this tool versus other creation tools (e.g., create_placement) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'Read-only', which indicates no side effects, but omits critical details such as error handling (e.g., if DPS ID is invalid), authentication requirements, or return format. This leaves significant gaps for a simple lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the core purpose. Every word earns its place with no redundancy or unnecessary detail.
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?
Given the tool's low complexity (single object retrieval), no output schema, and no annotations, the description is minimally adequate. It could improve by stating what is returned (e.g., 'Returns the full offer item object') or how errors are handled, but for a basic lookup it provides enough to start.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'DPS ID' but does not explicitly map it to the 'offer_id' parameter, and the 'access_token' parameter is entirely unexplained. The description adds minimal semantic value 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?
The description clearly states the action ('Look up'), the resource ('a single offer item'), and the identifier ('by its DPS ID'), effectively distinguishing it from sibling tools like 'list_offer_items' (listing multiple) and 'update_offer_item' (modification).
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?
The phrase 'Read-only' implies this tool is for retrieval without side effects, setting clear context. However, it does not explicitly state when to use it versus alternatives like 'list_offer_items' or 'update_offer_item', though the distinction is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only' and 'with pagination', which are key behavioral traits. This is sufficient for a safe read operation, though it could mention the return format or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundant information. It front-loads the core purpose and key behavioral note ('Read-only'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter documentation, the description is too brief. It does not explain return values, error handling, authentication token usage, or pagination behavior beyond stating its existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters but 0% description coverage. The description only mentions 'pagination' without mapping to limit/offset. For an AI agent, this provides minimal guidance on how to use the parameters, despite defaults being present in 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?
The description clearly states the action (List), the resource (offer items), and the scope (in the ExD catalog). It distinguishes this tool from siblings like get_offer_item (single item) and list_schema_descriptors (different resource) by specifying 'offer items'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Read-only' and 'pagination', which provide basic usage context. However, it does not explicitly state when to use this tool over alternatives like get_offer_item or other list tools, nor does it provide exclusions or guidance on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that updates use JSON Patch and require 'confirmed: true' to execute, but does not cover side effects, idempotency, error handling, or authorization beyond the access_token parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with action and method, immediately followed by a key condition.
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?
Covers main purpose and a critical precondition, but missing details on return format, error scenarios, and proper usage of the patches array; no output schema to supplement.
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?
Adds meaning to 'patches' by mentioning JSON Patch and to 'confirmed' by stating it must be true, but does not explain 'offer_id' or 'access_token', and schema has no descriptions (0% coverage).
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?
Description clearly states verb (update), resource (offer item), and method (JSON Patch operations), distinguishing it from sibling tools like get_offer_item and list_offer_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for updating offer items but lacks explicit guidance on when to use versus alternatives, such as comparing with get_offer_item for reading or create_* for new items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the confirmation requirement and preview behavior, but does not specify what happens if a fieldgroup with the same name exists or what the preview output looks like. The transparency is adequate but incomplete.
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 very concise, consisting of two sentences. The main action is front-loaded, and additional constraints follow. It is efficient with no filler.
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?
Given the tool has 4 parameters, no output schema, and no annotations, the description covers the core functionality and the key constraint (confirmed flag). However, it lacks details on error handling, prerequisites, and what the preview returns. It is functional but could be more complete.
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 description coverage is 100%, so the description adds minimal new meaning beyond restating schema descriptions. It does clarify the purpose of csv_text and the confirmed flag's role, but this is largely redundant with 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?
The description clearly states it creates an XDM fieldgroup from CSV column names and attaches it to a schema. The verb 'create' and resource 'fieldgroup' are specific, distinguishing it from sibling tools like 'create_collection' or 'add_schema_field'.
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?
The description notes it checks for existing fieldgroup and requires confirmed:true to execute, implying a preview mode. While it does not explicitly list when to use vs alternatives, the context and sibling names provide differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly describes as read-only, which is a key behavioral trait. Lists resources included, but does not mention auth requirements (only hinted by access_token param) or potential side effects. With no annotations, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loading key information ('full read-only inventory'). No wasted words, efficient and clear.
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?
Given no output schema, description adequately explains what the tool returns (inventory of listed resources) but lacks detail on output structure or format. Sufficient for basic understanding but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (access_token) with 0% description coverage. Description adds no meaning about this parameter, such as its purpose or requiredness. Agent must infer from context.
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?
Description clearly states it retrieves a full read-only inventory of ExD resources, listing specific resource types (offers, collections, etc.). It distinguishes from sibling tools that focus on individual resource operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for overview via 'full read-only inventory', but no explicit guidance on when to use this tool versus siblings (e.g., for specific resources) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses the tool's two-step behavior: preview via dry_run, then execute via confirmed. It implies a write operation but doesn't detail error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core purpose and key workflow details. Every sentence adds value with no wasted words.
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?
Given 5 parameters and no output schema, the description covers the main execution flow and critical flags. It lacks details on return values or error handling but is adequate for use.
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 80%, so the schema already documents most parameters. The description reinforces the dry_run/confirmed workflow but adds little meaning beyond the schema's parameter descriptions.
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 clearly states the tool bulk-creates ExD offer items from CSV rows, each row becomes one offer. This is specific and distinct from sibling tools like create_placement or create_ranking_formula.
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?
The description explains the preview-then-execute workflow using dry_run and confirmed parameters. However, it does not explicitly state when to avoid using this tool (e.g., for single offers) or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description reveals a behavioral requirement (confirmation) but does not disclose other traits like reversibility, permissions, or side effects. The confirmation flag is noted, which adds some transparency but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no redundancy. It front-loads the purpose and immediately provides usage guidance and a key behavioral requirement.
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?
The tool is relatively simple (deprecate a field). The description covers purpose, usage, and a parameter requirement. While it lacks details about the effect of deprecation or return values, these are somewhat implied. Given no output schema, it is fairly complete.
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 description coverage is only 33% (only field_path has a description). The description adds meaning by explaining that 'confirmed: true' is required and provides an example field path. However, it does not clarify the access_token parameter, leaving some gaps.
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 clearly states the action (deprecate), target (OOB Adobe-managed field), method (via descriptor), and gives examples (itemDescription, itemName). It effectively distinguishes from the sibling tool deprecate_schema_field for custom fields.
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?
Explicitly states when to use this tool ('for standard fields like itemDescription, itemName') and when not to ('for custom tenant fields use deprecate_schema_field'). Also notes the requirement for 'confirmed: true', providing clear usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool is read-only ('no data is written') and describes its analysis actions. However, it does not mention error handling for malformed CSV or specific behavior if schema inference fails, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. The first covers purpose and actions, the second provides critical usage guidance. No unnecessary words.
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?
The description adequately covers purpose and usage but lacks details about the return format of the suggestions (e.g., structure of proposed fields, eligibility rules). Since there is no output schema, the description could be more complete about what the agent can expect from the tool's output.
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?
The single parameter 'csv_text' has 100% schema description coverage, so the schema already fully defines it. The description adds no additional semantic meaning beyond what the schema provides, resulting in a baseline score of 3.
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 clearly states the tool's specific actions: parse CSV, infer XDM types, and suggest schema fields, eligibility rules, and ranking formulas. It also explicitly distinguishes itself from sibling tools by stating 'no data is written,' making it clear as a read-only analysis tool.
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?
The description explicitly instructs 'Always call this first — no data is written,' providing clear guidance on when to use this tool (before any writing operations) and implying it is a prerequisite step, effectively differentiating from sibling tools that create or modify data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that field remains but is flagged, and requires confirmation. No annotations provided, so description carries burden; lacks detail on reversibility or permissions but covers main effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no extraneous text. Efficient and well-structured.
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?
Covers key aspects: purpose, alternative, requirement. Missing details on output and definition_key parameter, but sufficient given tool simplicity.
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?
Description adds meaning by requiring confirmed: true and implying fieldgroup_id/field_name are needed, but does not explain definition_key or access_token. Schema coverage is 0%, so partial compensation.
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?
Describes marking a custom tenant fieldgroup field as deprecated, specifying verb and resource. Distinguishes from sibling deprecate_oob_field for OOB Adobe fields.
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?
Explicitly states when to use alternative (deprecate_oob_field) and requires confirmed: true to execute, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behaviors: safe removal, dry-run preview, and need for confirmation. Does not mention authentication or rate limits, but the safety and preview steps are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and safety. Every word adds value; no redundancy or fluff.
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?
Given no output schema and moderate complexity, description covers essential behavior (dry-run, confirmation). Could mention error cases or return format, but overall sufficient for agent decision-making.
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?
Description adds meaning beyond schema: explains fieldgroup_id can be altId or URI, and that confirmed must be true to execute. Schema coverage is 33%, but description compensates for two of three parameters, leaving access_token undocumented.
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?
Clearly states the tool removes a fieldgroup from the decisioning schema, with specific verb 'remove' and resource 'fieldgroup'. Distinguishes from sibling tools like create_collection or add_schema_field.
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?
Provides clear when-to-use: when you need to remove a fieldgroup. Mentions the dry-run preview and confirmation requirement, guiding the agent to use the tool safely. Lacks explicit exclusions or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Decisioning-mcp MCP server](https://glama.ai/mcp/servers/khushi-nayal/Decisioning-mcp/badges/card.svg)](https://glama.ai/mcp/servers/khushi-nayal/Decisioning-mcp)

Score Badge

Copy to your README.md:

[![Decisioning-mcp MCP server](https://glama.ai/mcp/servers/khushi-nayal/Decisioning-mcp/badges/score.svg)](https://glama.ai/mcp/servers/khushi-nayal/Decisioning-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/khushi-nayal/Decisioning-mcp'

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