aifais-mcp-server

Server Quality Checklist

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

Latest release: v1.3.1
Disambiguation4/5
Most tools have distinct purposes targeting specific business tasks like contract analysis, invoice generation, CV screening, and lead scoring. However, create_invoice and scan_invoice could potentially be confused as both handle invoices, though one generates and the other extracts data, which is clarified in descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as check_contract, create_invoice, and generate_quote. There are no deviations in naming conventions, making the set predictable and readable.
Tool Count5/5
With 10 tools, the count is well-scoped for a business utility server covering various professional tasks like document generation, analysis, and planning. Each tool appears to earn its place without feeling excessive or insufficient.
Completeness3/5
The server covers a broad range of business utilities, but there are notable gaps in lifecycle coverage. For example, tools like check_contract and generate_terms lack corresponding update or delete operations, and there's no clear domain-specific workflow integration, though agents can work around this for standalone tasks.
Average 3/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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

Behavior2/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 of behavioral disclosure. It mentions 'Free tool,' which hints at no cost, but doesn't cover other critical aspects like permissions needed, whether it's a read/write operation, rate limits, or what the output entails (e.g., PDF generation details). For a tool with 5 parameters and no annotations, this is a significant gap in transparency.
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 with two short sentences: 'Generates a professional PDF quote. Free tool.' It's front-loaded with the main purpose and adds a brief additional note. There's no wasted text, making it efficient, though it could benefit from more detail given the tool's complexity.
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 5 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the parameters, behavioral traits, or what the tool returns (e.g., PDF file, error handling). For a quote generation tool with multiple inputs, this leaves too many gaps for effective agent use.
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%, meaning none of the 5 parameters have descriptions in the schema. The tool description doesn't add any meaning about parameters like 'companyName', 'clientName', 'items', etc. It doesn't explain what these inputs represent or how they're used in quote generation, failing to compensate for the lack of schema documentation.
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 tool's purpose: 'Generates a professional PDF quote.' It specifies the verb ('Generates') and resource ('professional PDF quote'), making it clear what the tool does. However, it doesn't differentiate from sibling tools like 'create_invoice' or 'generate_terms', which might have overlapping purposes, so it doesn't reach the highest score.
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 provides minimal guidance: 'Free tool.' This implies no cost but doesn't specify when to use this tool versus alternatives like 'create_invoice' or 'generate_terms'. There's no explicit context, exclusions, or prerequisites mentioned, leaving the agent with little direction on appropriate usage scenarios.
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 carries the full burden of behavioral disclosure. It mentions the payment requirement, which is a useful behavioral trait (cost implication), but fails to describe other critical aspects such as what the output looks like (e.g., a text document, a file), whether it's a read-only or mutation operation, potential rate limits, or error conditions. For a tool with 11 parameters and no annotations, this is a significant gap in transparency.
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 and front-loaded, consisting of two sentences that directly state the purpose and a key requirement. There's no wasted verbiage, and it efficiently communicates essential information. However, it could be slightly improved by structuring usage guidance more explicitly, but overall, it's appropriately sized for its content.
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 complexity (11 parameters, low schema coverage, no annotations, and no output schema), the description is incomplete. It covers the basic purpose and payment aspect but lacks details on behavioral traits, parameter meanings, output format, and usage context. For a tool that generates legal documents with multiple inputs, this leaves significant gaps for an AI agent to understand and invoke it 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?
The schema description coverage is low at 36%, with only 4 out of 11 parameters having descriptions in the schema. The description does not compensate by explaining any parameters beyond what's implied (e.g., 'custom Terms & Conditions' hints at inputs like company details but doesn't specify semantics). It adds no meaningful details about parameter usage, formats, or constraints, leaving most parameters undocumented and unclear in context.
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 tool's purpose: 'Generates custom Terms & Conditions for a company.' It specifies the verb ('Generates') and resource ('custom Terms & Conditions'), making the function evident. However, it doesn't distinguish this tool from potential siblings like 'check_contract' or 'generate_quote', which might involve similar legal or document generation tasks, so it lacks explicit differentiation.
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 provides minimal usage guidance: it mentions a payment requirement ('Requires payment (0.005 SOL)'), which implies a cost context, but offers no advice on when to use this tool versus alternatives like 'check_contract' or 'generate_quote'. There's no explicit when/when-not guidance or mention of prerequisites beyond payment, leaving the agent with little direction on appropriate usage scenarios.
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 carries the full burden of behavioral disclosure. It states 'Generates a professional PDF invoice' and 'Free tool,' which implies a creation operation without cost, but lacks details on permissions, rate limits, output format (beyond PDF), error handling, or whether it's idempotent. This is a significant gap for a mutation tool with zero annotation coverage.
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 appropriately sized and front-loaded: 'Generates a professional PDF invoice.' is the core purpose, and 'Free tool.' adds a useful note. Both sentences earn their place by providing essential information without waste, making it efficient and well-structured.
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 complexity (8 parameters, mutation operation), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the return value (e.g., PDF file or link), error conditions, or parameter details, making it inadequate for an agent to reliably use this tool without additional context.
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 description adds no meaning beyond the input schema, which has 0% description coverage for its 8 parameters. It doesn't explain what parameters like 'ownName', 'clientAddress', or 'items' represent, their formats (e.g., date formats for 'invoiceDate'), or how 'items' should be structured. With low schema coverage, the description fails to compensate, leaving parameters largely undocumented.
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 tool's purpose: 'Generates a professional PDF invoice.' It specifies the verb ('generates') and resource ('PDF invoice'), and distinguishes it from siblings like 'scan_invoice' or 'generate_quote'. However, it doesn't explicitly differentiate from 'generate_quote' beyond the invoice vs. quote distinction, which is implied but not stated.
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 provides no guidance on when to use this tool versus alternatives. It mentions 'Free tool,' which might imply cost considerations, but doesn't specify contexts, prerequisites, or exclusions. For example, it doesn't clarify when to use 'create_invoice' over 'generate_quote' or 'scan_invoice', leaving the agent without explicit usage instructions.
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 mentions payment requirement (0.001 SOL) which is useful context about cost, but doesn't describe what the scoring output looks like, how prioritization works, whether this is a read-only analysis or creates records, or any rate limits/authentication needs. For a 7-parameter tool with complex nested objects, this leaves significant behavioral gaps.
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 at just two short sentences with zero wasted words. It's front-loaded with the core purpose followed by a critical prerequisite. Every sentence earns its place by providing essential information about what the tool does and its cost requirement.
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 complexity (7 parameters with nested objects), no annotations, no output schema, and low schema coverage (14%), the description is incomplete. It doesn't explain what the scoring output looks like, how to interpret results, what the prioritization criteria are, or provide sufficient parameter guidance. The payment requirement is helpful but doesn't compensate for other major gaps.
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 only 14% (only the 'signature' parameter has a description). The description doesn't add any parameter meaning beyond what's in the schema - it doesn't explain what 'companySize' values are expected, what 'budget' format to use, how 'engagement' metrics affect scoring, or what 'notes' should contain. For 7 parameters with low schema coverage, the description fails to compensate.
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 tool's purpose: 'Scores and prioritizes leads' - a specific verb+resource combination. It distinguishes from most sibling tools (e.g., create_invoice, pitch_deck) by focusing on lead evaluation rather than document generation or contract checking. However, it doesn't explicitly differentiate from cv_screener which also involves scoring/evaluation.
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 provides minimal guidance: 'Requires payment (0.001 SOL)' indicates a prerequisite but doesn't explain when to use this tool versus alternatives. No context about when this scoring is appropriate versus other lead management approaches, and no mention of sibling tools like cv_screener that might handle different scoring scenarios.
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. It discloses the payment requirement, which is useful behavioral context, but lacks details on what 'generates' entails (e.g., format, output type, rate limits, or error handling). This is inadequate for a tool with 8 parameters and no output schema.
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 with two sentences that directly state the purpose and a key requirement. Every word earns its place, and it's front-loaded with the main function.
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 complexity (8 parameters, 5 required), low schema coverage (13%), and no output schema, the description is incomplete. It doesn't explain what the tool returns, how parameters interact, or behavioral aspects beyond payment, leaving significant gaps for an AI agent.
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 low at 13%, with only one parameter ('signature') having a description. The tool description adds no information about parameters beyond the payment note, failing to compensate for the coverage gap. For example, it doesn't explain what 'slideCount' or 'askAmount' mean in context.
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 tool 'Generates a pitch deck structure,' which is a specific verb+resource combination. It distinguishes from siblings like 'generate_quote' or 'social_planner' by focusing on pitch decks, though it doesn't explicitly differentiate from all alternatives.
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 payment (0.001 SOL),' which provides some usage context, but it doesn't specify when to use this tool versus alternatives (e.g., 'generate_terms' or 'lead_scorer'), nor does it outline prerequisites or exclusions beyond payment.
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 of behavioral disclosure. It adds some context: the payment requirement hints at transactional behavior and potential costs. However, it doesn't describe key traits like how the scoring works (e.g., algorithm, scale), what the output includes (e.g., scores, feedback), error handling, or rate limits. For a tool with no annotations and complex functionality, this is insufficient.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds a critical constraint (payment). There's no wasted text, and both sentences earn their place by providing essential information. However, it could be slightly more structured (e.g., separating purpose from requirements), but it's efficient overall.
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 complexity (CV analysis and scoring), no annotations, no output schema, and 4 parameters, the description is incomplete. It lacks details on behavioral aspects (e.g., scoring methodology, output format), parameter usage, and how it fits among siblings. The payment note is helpful, but for a tool with significant functionality gaps, more context is needed to make it fully actionable.
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 75% (3 out of 4 parameters have descriptions), so the baseline is 3. The description doesn't add meaning beyond the schema: it mentions CV and job description but doesn't explain parameter interactions (e.g., how 'cvBase64' and 'mimeType' relate, or what 'signature' is for beyond the schema's note). It compensates slightly by implying the tool uses these inputs, but not enough to exceed the baseline.
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 tool's purpose: 'Analyzes and scores a CV against a job description.' It specifies the verb ('analyzes and scores'), resource ('a CV'), and target ('against a job description'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'lead_scorer' or 'interview_questions', which might involve similar scoring or analysis tasks, so it doesn't reach the highest score.
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 provides minimal usage guidance: it mentions a payment requirement ('Requires payment (0.001 SOL)'), which is a prerequisite but not a contextual guide. It doesn't specify when to use this tool versus alternatives (e.g., 'lead_scorer' for leads, 'interview_questions' for generating questions), nor does it outline exclusions or ideal scenarios for CV screening. This lack of comparative context limits its helpfulness.
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 carries the full burden. It discloses a payment requirement, which is a key behavioral trait, but lacks details on error handling, rate limits, output format, or processing time. For a tool with no annotations and complex functionality, this is insufficient.
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-loaded with the core purpose and followed by a critical requirement. Every word serves a clear function, with no redundancy or unnecessary elaboration, making it highly efficient.
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 no annotations, no output schema, and a tool that performs a complex operation (invoice scanning with payment), the description is incomplete. It misses details on output structure, error cases, and operational constraints, leaving significant gaps for an AI agent to use it effectively.
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 schema fully documents the three parameters. The description adds no additional meaning beyond implying the 'signature' parameter relates to payment, but this is minimal. Baseline 3 is appropriate as the schema handles most of the parameter documentation.
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 tool's purpose with a specific verb ('scans') and resource ('invoice'), specifying file formats (PDF/JPG/PNG) and outcome ('extracts structured data'). It doesn't distinguish from sibling tools, but none appear to be direct alternatives for invoice scanning, making this adequate.
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 a requirement ('Requires payment (X402)'), which provides some usage context, but it doesn't specify when to use this tool versus alternatives (e.g., if 'create_invoice' or other siblings are related), nor does it provide exclusions or clear scenarios for application.
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 of behavioral disclosure. It mentions a payment requirement (0.001 SOL), which is useful context for cost and authentication needs, but fails to describe other critical behaviors such as rate limits, response format, error handling, or whether the operation is idempotent. This leaves significant gaps for a tool that involves financial transactions.
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 with two sentences that directly state the tool's function and a key requirement. There is no wasted language, and it is front-loaded with the primary purpose, making it efficient and easy to parse.
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 complexity of a paid tool with 5 parameters, low schema coverage (20%), and no output schema or annotations, the description is incomplete. It mentions payment but omits details on parameter usage, return values, error cases, and behavioral constraints, which are essential for safe and effective tool invocation in this context.
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 low at 20%, with only one parameter ('signature') having a description. The tool description adds no information about parameters beyond what's in the schema, failing to compensate for the coverage gap. For example, it doesn't explain what 'jobTitle', 'jobDescription', or 'experienceLevel' should contain, or how 'questionCount' affects output.
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 tool's purpose with a specific verb ('Generates') and resource ('personalized interview questions'), making it immediately understandable. However, it doesn't differentiate this tool from potential sibling tools that might also generate content, such as 'generate_quote' or 'pitch_deck', which could create ambiguity in tool selection.
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 usage by mentioning a payment requirement, suggesting it should be used when the user is willing to pay for interview questions. However, it lacks explicit guidance on when to use this tool versus alternatives like 'cv_screener' or other content-generation siblings, and doesn't specify prerequisites beyond payment.
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 full burden of behavioral disclosure. It reveals the payment requirement (0.001 SOL cost) which is valuable context not in the schema, but doesn't disclose other important behavioral traits like whether this is a read-only or write operation, rate limits, authentication needs, or what the generated plan includes. The description adds some value but leaves significant gaps.
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 with just two sentences that each serve distinct purposes: stating the core functionality and disclosing the payment requirement. There's zero wasted language, and the most critical information (payment requirement) is appropriately front-loaded in the second sentence.
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 6-parameter tool with no annotations, no output schema, and minimal schema descriptions, the description is insufficiently complete. It doesn't explain what the tool returns (a content plan format), how parameters interact, or provide enough context for an agent to understand the tool's behavior beyond the basic purpose and cost. The payment disclosure is helpful but doesn't compensate for other gaps.
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?
With only 17% schema description coverage (only the 'signature' parameter has a description), the description provides no information about any of the 6 parameters. It doesn't explain what 'topic', 'platforms', 'postCount', 'tone', or 'includeHashtags' mean or how they affect the content plan generation. The description fails to compensate for the low schema coverage.
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 tool's purpose as 'Generates social media content plan' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'generate_quote' or 'pitch_deck' by focusing on social media planning. However, it doesn't explicitly differentiate from potential similar content generation tools beyond the social media context.
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 provides minimal usage guidance with 'Requires payment (0.001 SOL)' indicating a cost prerequisite, but offers no guidance on when to use this tool versus alternatives like 'generate_quote' or 'interview_questions'. There's no mention of appropriate contexts, exclusions, or comparison with sibling tools for content generation tasks.
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 key behavioral traits: the tool requires payment (0.01 SOL) and analyzes contracts, implying it's a read-only analysis tool. However, it lacks details on rate limits, error handling, or what the analysis output includes (e.g., risk levels, specific clauses), which are important for a tool with no output schema.
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) and front-loaded with the core purpose, followed by the payment requirement. Every sentence earns its place by providing essential information without redundancy or fluff.
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 complexity (contract analysis with payment), lack of annotations, and no output schema, the description is incomplete. It covers the purpose and payment need but misses details on output format, error cases, or analysis scope (e.g., types of risks). This is adequate as a minimum but has clear gaps for effective agent 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 description coverage is 100%, so the schema already documents both parameters (contractBase64, signature). The description adds value by explaining that the signature is for 'payment proof', which clarifies its purpose beyond the schema's generic description. However, it does not provide additional semantics for contractBase64 or detail payment processing, so it meets the baseline for high schema 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?
The description clearly states the tool's purpose with a specific verb ('Analyzes') and resource ('legal contract'), plus the specific function ('for risks and missing clauses'). It distinguishes itself from sibling tools like 'generate_terms' or 'scan_invoice' by focusing on contract analysis rather than generation or invoice processing.
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 provides clear context for when to use this tool (analyzing legal contracts for risks and missing clauses) and includes a critical prerequisite (payment requirement). However, it does not explicitly state when NOT to use it or name alternatives among siblings, such as using 'generate_terms' for creating contract terms instead of analyzing them.
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:

[![aifais-mcp-server MCP server](https://glama.ai/mcp/servers/markjkaem/aifais-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/markjkaem/aifais-mcp-server)

Score Badge

Copy to your README.md:

[![aifais-mcp-server MCP server](https://glama.ai/mcp/servers/markjkaem/aifais-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/markjkaem/aifais-mcp-server)

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/markjkaem/aifais-mcp-server'

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