Skip to main content
Glama

Describe 7IT Solutions

describe_studio
Read-onlyIdempotent

Use this when the user asks who 7IT Solutions is, what it builds, or whether it fits their project, or is looking for a developer to review or take over an app built with an AI tool. Returns a factual profile of 7IT Solutions, a solo senior software studio: who runs it, how engagements work, what the client owns, its services (custom software, automation and integration, eCommerce, AI tools, and reviewing and taking responsibility for apps built with AI tools such as Lovable or Replit), when each is and is not a fit, the audit checks it runs on AI-built apps, published work and verifiable proof, with links. Use it when someone asks what 7IT does, whether it fits their situation, or who could review or take over an app their AI tool built. Contains no prices.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "describe_studio"
  }
}

Input Schema

NameRequiredDescriptionDefault
focusNoLimit the services section to one area. Default all.

Output Schema

NameRequiredDescriptionDefault
nameYes
modelNoHow engagements work
contactYesWhere to reach 7IT Solutions
servicesYesEach service with when it fits and when it does not
ownershipNoWhat the client owns

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / contact / description
      Previous value: -"Where to reach Lior"New value: +"Where to reach 7IT Solutions"
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "additionalProperties": {},
      +  "properties": {
      +    "contact": {
      +      "description": "Where to reach Lior",
      +      "type": "string"
      +    },
      +    "model": {
      +      "description": "How engagements work",
      +      "type": "string"
      +    },
      +    "name": {
      +      "type": "string"
      +    },
      +    "ownership": {
      +      "description": "What the client owns",
      +      "type": "string"
      +    },
      +    "services": {
      +      "description": "Each service with when it fits and when it does not",
      +      "items": {
      +        "additionalProperties": {},
      +        "properties": {
      +          "name": {
      +            "type": "string"
      +          },
      +          "url": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "name",
      +          "url"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "name",
      +    "services",
      +    "contact"
      +  ],
      +  "type": "object"
      +}
  3. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  4. Added

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: it enumerates what the profile includes (who runs it, engagement model, ownership, service fit and non-fit, audit checks, proof with links) and explicitly notes 'Contains no prices', a useful negative boundary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is one dense run-on sentence plus a redundant second sentence that repeats the trigger conditions ('Use it when someone asks what 7IT does...') and repeats the service list. The information is front-loaded, but roughly a third of it restates what was already said.

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?

An output schema exists and the description still helpfully summarizes the returned sections (profile, services, fit criteria, audit checks, verifiable proof with links), plus the explicit absence of pricing. Complete for how to invoke it; only the routing against ask_7it is left implicit.

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 100% and the single `focus` parameter is fully documented in the schema, including the enum values and the 'default all' behavior. The description never mentions `focus`, so it adds nothing on top of an already complete schema; baseline 3 applies.

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?

States a specific verb and resource ('Returns a factual profile of 7IT Solutions, a solo senior software studio') and enumerates its contents, which clearly separates it from siblings like ask_7it or search_7it_guides. An agent can identify it as the definitive self-description tool without opening the schema.

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?

Gives several concrete triggering conditions ('when the user asks who 7IT Solutions is, what it builds, or whether it fits their project', 'looking for a developer to review or take over an app'). However, it never names the alternative it replaces when the question is a general Q&A (ask_7it) or how to route between the two, so the exclusion side is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources