NCTR Alliance rewards — search bounties, check earning rates, and discover communities.
Scored across 6 tools
Most tools target clearly distinct resources: tiers, promotions, earning rates, impact engines, onboarding links, and bounties. The only mild overlap is between get_active_promotions and search_bounties, since both surface earning opportunities, but their descriptions differentiate offers from bounty listings.
All tool names use a consistent snake_case verb_noun pattern: check_tier_requirements, get_active_promotions, get_earning_rates, get_impact_engines, get_onboarding_link, and search_bounties. The choice of get/check/search is predictable and readable.
Six tools is well-scoped for an informational server about NCTR Alliance. Each tool covers a distinct area of member knowledge without unnecessary surface area.
The server covers the core informational needs: tier progression, earning rates, promotions, communities, onboarding links, and bounty search. Minor gaps exist, such as no tool to retrieve a specific member's current tier or status, but the main workflows are covered.
Check what is needed to reach a specific Crescendo status tier, or see the full progression path. Shows NCTR commitment thresholds, earning benefits, and rewards for each tier.
| Name | Required | Description | Default |
|---|---|---|---|
| target_tier | No | Target tier to check requirements for | |
| current_balance | No | Current NCTR balance to check tier status and progress to next tier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It implies a read-only informational operation ('Check', 'Shows') and lists the categories of information returned, but does not explicitly state that it is non-mutating, what permissions are needed, or how errors are handled.
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 efficient sentences that front-load the tool's purpose and then list the information obtained. Every sentence earns its place.
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?
The tool has no output schema and no annotations, so the description should explain return categories and safety profile. It does explain what data is shown (thresholds, benefits, rewards) and implies read-only access, though it could more explicitly confirm that the operation has no side effects.
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 description coverage is 100%, and both parameters are already documented in the schema. The description does not add parameter-specific meaning beyond the schema, so baseline 3 applies.
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 and resource: checking Crescento tier requirements, thresholds, benefits, and rewards. It distinguishes itself from most siblings by being the tier-progression lookup, though it does not explicitly name related tools like get_earning_rates or get_active_promotions.
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 description implies two usage modes: check a specific target tier, or see the full progression path. However, it does not say when to use this tool versus sibling tools such as get_earning_rates or get_active_promotions, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explore active offers and earning opportunities in NCTR Alliance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and discloses almost nothing beyond an implied read. It does not say whether results are paginated, whether auth or alliance membership is required, or what a 'promotion' record contains.
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?
A single short sentence with no padding, but the brevity comes at the cost of precision rather than from careful editing.
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?
No output schema and no annotations, so the description is the only place an agent could learn what this returns and how it relates to the sibling earning tools. It does not fill that gap, leaving the agent to call blind.
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?
The tool takes zero parameters, so the baseline is 4; there is nothing the description needs to disambiguate at the input level.
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 names the resource ('active offers and earning opportunities in NCTR Alliance'), which hints at promotions, but the verb 'Explore' is vague and the word 'promotions' from the tool name never appears. An agent can loosely infer it differs from get_earning_rates or search_bounties, but the distinction is not made explicit.
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?
There is no statement of when to call this versus the siblings get_earning_rates, search_bounties, or get_impact_engines, all of which touch adjacent earning concepts. The agent must guess at routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get NCTR earning rates for a specific Crescendo status tier, or compare all tiers. Shows how your status sets what you earn on every bounty. Higher tiers earn more NCTR per bounty.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Specific tier to check. Omit to see all tiers. | |
| bounty_id | No | Optional bounty ID to calculate tier-adjusted earning amount |
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 implies a read-only lookup and explains that higher tiers earn more NCTR per bounty, which is useful domain context, but it says nothing about authentication, data freshness, or the shape of the returned rates, leaving real gaps for an unannotated tool.
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?
Three short sentences, front-loaded with the core action and the two modes. The final line about tiers earning more is mildly redundant with the first sentence but still useful framing rather than filler.
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 simple read-only tool with two optional parameters, no output schema, and no nested objects, the description covers purpose, modes, and the tier-earnings relationship well. The gap is that bounty_id's role is only explained in the schema, so the description alone would leave an agent unsure about that parameter.
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 description coverage is 100%, so both parameters are already documented in the schema, establishing a baseline of 3. The description reinforces the tier-omission behavior but never mentions bounty_id or what a tier-adjusted earning amount means, adding little beyond the schema.
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 states a specific verb and resource — get NCTR earning rates — and scopes it to two clear modes: a single Crescendo status tier or a comparison across all tiers. It also distinguishes the concept from sibling tools like check_tier_requirements and search_bounties by naming the earning-rate domain explicitly.
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?
It tells the agent both usage modes: pass a tier for one tier, or omit it to compare all tiers. There is no explicit when-not-to-use guidance or named alternative among the siblings, 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.
Discover NCTR Impact Engine communities. Impact Engines are passion-based communities within NCTR — each focused on a different lifestyle vertical. Members can join any Impact Engine to connect with like-minded people and access community-specific experiences.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category (Powersports, Lacrosse, Entertainment, Skilled Trades, Recovery, Wellness) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what Impact Engines are, but not what the tool actually returns, whether it supports filtering, or whether it has side effects like joining a community.
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?
The description is three sentences and front-loads the purpose. The additional context about Impact Engine communities is useful, though slightly verbose for a simple list tool.
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?
With no output schema and no annotations, the description is minimally sufficient: the name and first sentence imply a list operation, and the schema covers the optional filter. However, return format and filtering behavior are left implicit.
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?
The schema description for the category parameter is 100% complete, listing all possible values. The tool description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 applies.
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 opens with 'Discover NCTR Impact Engine communities', using a specific verb and resource. It clearly distinguishes the tool from siblings focused on promotions, requirements, funding, and search.
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 first sentence 'Discover NCTR Impact Engine communities' gives clear context for when to use the tool. It does not mention explicit exclusions or alternatives, but the purpose is unambiguous among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a link for a new member to join NCTR Alliance. Optionally include a referral code. Returns the sign-up URL and a summary of what new members earn.
| Name | Required | Description | Default |
|---|---|---|---|
| referral_code | No | Optional referral code to credit the referring member |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It states that the tool generates a link and returns a sign-up URL plus earnings summary, but it does not mention any side effects, permissions, or whether the operation is persistent. It adds some return-value context but lacks deeper behavioral transparency.
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?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. Every word contributes to understanding the tool's function and return value.
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 simple tool with one optional parameter and no output schema, the description covers the key elements: what it generates, the optional parameter, and what it returns. It is slightly incomplete in not addressing potential caveats like link expiration or authentication, but it is adequate for the tool's simplicity.
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% for the single parameter referral_code, and the schema description already explains its purpose. The description restates that the code is optional and credits the referring member without adding meaningful new information beyond the schema.
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 clearly states the tool generates a link for a new member to join NCTR Alliance, with an optional referral code. This is a specific verb+resource combination that distinguishes it from sibling tools focused on requirements, promotions, rates, funding, and bounties.
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 description implies the tool is for creating onboarding links, but it does not explicitly state when to use it over alternatives or provide exclusions. No mention of when not to use it or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter available NCTR bounties. Filter by category (entry, shopping, merch, referral, engagement), minimum/maximum NCTR amount, or keyword. Returns bounty details including name, amount, commitment period, and requirements. Every bounty is committed through 360LOCK for 360 days. Your NCTR stays yours throughout.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Search keyword to match against bounty name, description, or tags | |
| category | No | Filter by bounty category: entry, shopping, merch, referral, engagement | |
| max_amount | No | Maximum NCTR amount | |
| min_amount | No | Minimum NCTR amount | |
| repeatable_only | No | If true, only return bounties that can be earned multiple times |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and adds useful domain context: returned fields, 360LOCK commitment period, and non-custodial NCTR handling. It still omits pagination, result limits, authentication, and rate-limit behavior, so it is not fully transparent.
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?
The description is front-loaded with purpose, then filters, then return values, then commitment context. Every sentence contributes useful information without repetition or filler.
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 search tool with no output schema, the description explains the returned bounty details and the 360LOCK commitment context. It is nearly complete for invocation, though it lacks result limits, ordering, and pagination behavior.
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 schema already documents all five parameters. The description mentions keyword, category, and amount filters but omits repeatable_only and adds little beyond the schema's own descriptions.
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 and resource: search and filter available NCTR bounties. It names the filterable dimensions and return fields, making the tool's scope unmistakable and distinct from the informational sibling tools.
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 description makes clear how to filter bounties, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied by the search/filter language rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_bounties2 fields changedInput schema / properties / category / descriptionPrevious value: -"Filter by bounty category"New value: +"Filter by bounty category: entry, shopping, merch, referral, engagement"Input schema / properties / category / enumRemoved value: -[
- "entry",
- "revenue",
- "merch",
- "referral",
- "engagement"
-]get_ecosystem_fundingget_ecosystem_fundingcheck_tier_requirementsget_active_promotionsget_earning_ratesget_impact_enginesget_onboarding_linksearch_bountiesSearch and commission verified human research review through funded Research Bounties.
Discover verified deep-tech engineering bounties from any AI agent.
Open, paid bounties AI agents can claim, verified hourly from funded boards and audit contests.
A public bounty board where AI agents do paid work. USDC on Base, paid on accepted delivery.
Add one secure layer between your agents and this server.
